Table of Contents

Getting Started…………………………………………………………………………………………………………………………........2

Document Overview………………………………………………………………………………………………………………………...2

API Covers………………………………………………………………………………………………………………………………………….2

API Adapter……………………………………………………………………………………………………………………………………….2

Testing Environment………………………………………………………………………………………………………………………….5

Possible Solutions………………………………………………………………………………………………………………………………5

Fully Automated………………………………………………………………………………………………………………………………..5

Partial Automation…………………………………………………………………………………………………………………………….7

Manual Integration……………………………………………………………………………………………………………………………8
Getting Started
This document is a research document of API integration Automation. As we have a e-commerce
SaaS based application Ally, and we have different vendors who bought the solution but sometime
every vendor wants to use different Shipment API integration. The problem is here we have to put
efforts every time to integrate new shipment company API integration with ally. We will discuss
about different possibility to minimize the efforts.

Document Overview
First of all, in this document we will discuss different API types for example RESTful or SOAP based
API, we mainly covers Fedex, armax and shipa API documentation as we have done research mostly
upon these third party API. Then we will discuss three solution Fully automated , partial automated
and manual integration.

API endpoint we consider initially

Endpoint will be three for automation

1. Create Order
2. Track Order
3. Cancel Order

Whenever we try to integrate any of shipment API there are different type of API protocol, security
and error handling. For ex. Aramex API are soap based which are XML base API. So if we have to set
up something API adapter of our own then we have to consider that we can to import XML for soap
based service and JSON request response for RESTful API. These request and response will create
automatic C# class on behind the scene.

So, in this similar ways, we have to consider security protocol of every services, it may be simple web
authentication, token based authentication, or any other security. So our code should be dynamic to
support any kind of security protocol.

When we have SOAP based services then we have to do Add reference in Visual Studio or any IDE
and provide the WSDL but on the other hand we can directly call URL in case of RESTful service and
post the request and receive the response.
Above snapshot is for service reference of Aramax Shipment API.

API Adapter
Requirement to create our own API Adapter

1. A web or window form application which will have some forms to create code automatically
behind the scene.
2. Another Forms needed for testing the environment.

Exceptions Need to Consider while Automation.

I have gone through the documentation of Fedex and found that sometime when we have SOAP
service to visual studio it through compile time error. Below is the screenshot for the same
documentation of best practice by Fedex. This type of things should keep in mind while adding WSDL
information through our own UI, it might cause problem while compile the error, need to take care.
Testing Environment
There are two tools in market for testing web services which are widely use. POSTMAN which is used
for RESTful services and SOAPUI which is used for SoapServices. So If we develop some kind of API
adapter UI platform we have to provide similar kind of testing environment like POSTMAN and
SOAPUI provided but with minimum technical information. This is a huge effort to make testing
environment but on the other hand, it is a need of time. Without testing environment, we can’t
make sure our API adapter API writing down the code in correct way and on click publish it will start
working like charm.

SOAP Extraction Article can help to make a API adapter UI.

https://www.codeproject.com/Articles/18950/Dynamic-Discovery-and-Invocation-of-Web-Services

Possible Solutions

1. Fully automated

Below is the Mock Up of API Adaptor UI

On the click of Generate Code, it will write down C# Class with extract the properties from the
request body and response body section. And it will create a SQL server Entry point for Example it
will created class with First name of the API like FEDexCreateOrder.cs

And in database, it will save the name of API active integration. On the application level we can
switch ON or OFF any kind of Web Service.

We have to write down generic code for when we have any order in ally, it will check at application
level the name of Web services for example if name of web service in database at application level is
Shipa, then it will dynamically go to endpoint create order and pick the request response classes
from above generated code and call the API.

Above detail is to develop our own API adapter which is more complicated solution and time taking
activity and if we go for this solution we have to first develop a Proof of concept POC and first of all
technical team should get to gather to discuss the feasibility and open question of the design I am
providing above.

There is a another option to use third party API adapter.

Demo of API adapter : https://www.advsyscon.com/blog/rest-api-adapter/

2. Partial Automation
In the partial solution, we have to do one time investment on manual integration with one of
third party API with generic code with the helpful of database. We will store more
information into database like which API gateway is active right now. So we will provide
radio button option at Ally admin like 1. Fedex 2. Shipa 3. DHL one of them API will be active
for particular customer means Super Admin will active this for Admin user which will be our
vendors. Backend code automatically connected with these API. In case future we will have
new shipment company come in picture, we have to one time database entry and we have
to write down request and response classes which is partially effort for developer, it will
start working automatically behind the scene.

SQL tables for Shipment API

Company ID Shipment API ID IsActive

APIDetail
ID shipmentApiID APIName ClassName Namespace

With the help of c# reflection we will create runtime object of ClassName and write down
generic code of create order, track order and other API which will have parameter T as
Generic where T will come value from database at runtime.

Apart from above UI we can active any of API integration or switch API integration any time as per
requirement. When we have new API integration there we need to add a database entry with script
of new name. There will be a new radio button after refresh the page started coming here. But on
the other hand side we have to write down some classes in c# for request and response and few
database entries, we can more automate to do database entry from UI rather than scripting. We can
minimize the efforts of database scripting. For example below screen to set up a new shipment API
company.

3. Manual Integration:
As we are already doing the manual solution for every new api, we have to write down the
code from scratch and this code will be always separate solution for every new up-coming
shipment api integration. For example we have shipa api solution. Similar way whenever we
will another api we will write down all the code separate so it will use with anywhere with
hosting on server or we can also include it with other project solution. Manual integration
has its own advantages like we can write down RESTful API and Soap API service separately
which is a solid principle of software developer , easy to read code, extensibility , code of
concern.