In this article we'll explain how to test the integration between different systems through APIs, even when there is no availble connector in i2factory for the system you want to test.
Using the debug-only account (free to use) it can be used for:
- Understanding how an API will work with other systems.
- Defining a list of actions or event steps such as use case.
- Simply learning about how APIs work.
When we want to integrate a system that uses a REST API as a means of returning data, one of the firsts steps is to perform an analysis of the communication interface. Whilst conducting this analysis it’s necessary to carry out a series of small tests to verify it’s function and at the same time familiarise ourselves with it’s entities (for example: customer, product, order), methods (such as: create client, product delete) and data structure.
There are various ways you can perform these tests:
- The most daring developers will use tools like Curl to make requests and to check responses from API’s.
- Others will write their own programs that perform HTTP requests and process the answers.
- There are also simpler methods that are currently being used by a large number of developers. These options use programs specialised in sending HTTP requests. Normally these programs have a simple and powerful interface and they allow us to configure any aspect of the request, however using these types of programs requires a knowledge of HTTP basic concepts such as URL’s, Headers, Body, Coding etc. The most famous tools in this area are SoapUI and Postman, although there are many others such as Paw, RESTClient and RESTtest...
It's worth mentioning that all of them have a graphical interface in common that allows us to configure the different parameters necessary to make the requests and to visualise the received response. Most of these applications allow us to generate the code of the clients of the API’s in different languages of programming.
With these types of tools you should be able to test any REST API simply ( of course everything will depend on the architecture and design of the interface), although the user will still have to correctly indicate each of the parameters that intervenes in the request, including authorisation credentials.
Usually configuring this information is quite complex as there are many protocols and implementations of security systems that verify authentication and authorisation in the API.
Put simply it’s job is to obtain authentication data such as access token, apikey and passwords through a slightly complex process. We'll include all of this information in every request that we make to the API.
Once we’ve tested the APIs with the different services that we’re going to integrate, the next step should be to carry out a small integration test to check the compatibility of the systems and the mapping of the data between different services. We could generate the clients of the APIs, import them into our development environment and manually program the integration, a task that is not always easy and requires us to have different tools and programming knowledge.
How to test APIs with i2factory
If you do not have an active account, sign up now for a free debugging account:
With i2factory we can perform these tests in a simple way using the functionality provided by the HTTP connector. This is a protocol connector that allows us to configure all aspects of HTTP requests (url, header, body, method etc) necessary to perform the tests on the API’s of the services we want to integrate with.
We would conduct the same test as if we were testing an API however this connector offers two additional advantages.
- On one hand, it has generic credentials such as oauth2, basic and apikey.
This function allows us to forget the specific details of the authorisation information. We simply create a credential with the necessary data and configuration, select it in the connector and the information will be automatically added to the user transparently in all requests.
-This prevents us from manually defining the authorisation headers or parameters in each of the requests. The advantage of this mechanism is more evident in the credentials of oauth2 type, where we only need to register our application in the service and configure the process data of oauth2. The resulting accessToken will be added automatically and transparently to the requests. Of course, there is always the possibility to manually define the authorisation information using headers, body and URL of the HTTP request.
- The other great benefit is the ability to take advantage of the tests on the API to easily perform a more complete test in which we can even check the possibilities of integration and compatibility of the data with other systems. Once the connection to the API is made we can continue the integration, also using all the catalog of connectors available in i2factory.
To show these capabilities we will perform a small integration between the services of LemonStand (an e-commerce platform) and Magneto. In this case we will assume that we are interested in migrating client data from Lemonstand to Magneto. i2factory currently has a Magneto connector, however at this moment in time there is no connector for Lemonstand, so we will use the HTTP connector to communicate with your API.
Firstly we have to consult the documentation of the LemonStand API to determine the structure of the requests and the type of authentication. In this case it is an authorisation of type apikey that is sent in the “Authorisation” header of the HTTP request next to the variable “Bearer”.
To perform the tests with the LemonStand API using the HTTP connector of i2factory we will create the access credential. To do this, go to the credentials section, click on add new credential and select the HTTP connector and once the form appears we choose “apikey”. This form is shown below.
We must enter the authorisation values for our LemonStand store: we choose an alias and then a description to identify the credential and we enter the apikey (we must obtain it from the control panel of LemonStand).
Then select "Header" in the type of transport (since apikey is sent through the header, not in the same URL), we don't indicate coding since apikey is not coded in this case. Finally as a parameter name we enter "Bearer".
Once the credential is created, access the solutions section and create a new integration solution in which we will include an HTTP input connector. .
In the credential alias we select the alias of the credential that we have created previously, in this case "credLemonStand", and in the command selector we chose "Request (json)" since the LemonStand API returns the data in JSON format. This command allows you to translate the JSON format of the request into the XML format which is used inside the platform to operate on the data.
In order to complete the solution and perform the tests with the LemonStand API we'll use a Mock output connector that will take care of the message and the translator with a simple mapping. We'll save the solution, activate the debugging mode and click "Run".
When the execution is finished we can consult the service response by selecting the link between the HTTP connector and the translator. In the right pane in the "Message" section we see customer information.
Once the operation of the LemonStand API has been checked, we can continue with the next step of performing a small integration test that allows us to see the compatibility of the data between LemonStand and Magento.
We've done most of the hard work, we now simply need to replace the Mock output connector and configure the element mapping in the Translator task.
This is an example of element mapping between the HTTP Connector connected with LemonStand and the Magento connector in your Client Authoring command. It associates the email data, name and surnames obtained from the request to LemonStand with the equivalent fields in the input schema, the new functionality has been used to obtain the schema from a sample message.
This function will be available soon in i2factory.
Looking at the generated XSLT code we can see how a set of fixed values correspond to the labels of the message that Magento needs to create a client (MagentoCustomer, customer, email, first name, last name) while other tags exist (xsl: value-of…) corresponding to selection expressions on the elements of the message entered by the HTTP connector, which contains the data of LemonStand.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
Within the selection expression on the elements of LemonStand we can define two parts:
The first part of the expression (in red) is common to all messages entered by HTTP connector requests, while the green part is specific to this example with LemonStand, since it corresponds to the transformation of the data of that API (Which is in json format) to XML.
Thanks to the power of i2factory and the catalog of connectors available, we can easily modify the solution by replacing the output connector and modifying the translator to test the possibilities of integrating LemonStand with other electronic commerce, such as WooCommerce.
The corresponding mapping is similar to the previous one and by making a few changes we can connect our LemonStand with WooCommerce.
If we take a look at the generated XSLT code we can see how the value selection expressions on LemonStand ((xsl:value-of…) do not change, only the structure that surrounds them does.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
As demonstrated with i2factory we can perform tests on any REST API and from these tests perform a fully functional integration very simply.
Solutions built in this way are fully functional (albeit more lengthly than development with the complete connector) and can be run in productive environment without any problems.