Selecting the right interfaces for a sustainable p2p solution
Preface
Cloud-based P2P solutions have been there in the market from the late ’90s and the market was highly dominated by some prominent ERP specialists taking it to cloud solutions by taking procurement solutions into the right hands of a Procurement Manager and managing a wide variety of procurement needs of an organization.
As time went by they have become a primary ingredient for corporate procurement as the tools started adding up sourcing methodologies thereby maintaining end to end transparency of a transaction right from supplier negotiations to placing an order and to payment of the Invoice.
The next phase of corporate procurement dealt with increasing the visibility of spend as well as reducing deduplication efforts for the procurement managers and it soon surfaced that the only way to reduce the duplication effort of a buyer/procurement manager was to integrate the system with the backend ERP.
With the new possibilities of integration, problems of performance, reliability started to play a bigger stake in how the organizations define their Interfaces between ERP and the cloud-based applications. Through this note, we attempt to explore some possible integration scenarios for Ivalua- a leading cloud based procurement software, their approach and the associated pros and cons.
Scenario – I
Ivalua Integration with SAP ECC using SFTP connection
Integration interfaces are asynchronous using SFTP connections between Ivalua and SAP. Files exchange is established via Ivalua file server using secure connections.
Following (both to and from SAP) touchpoints were considered:
- Supplier Creation/Changes/Extension/Block.
- Requisition Creation/Update/Deletion.
- Purchase Order Creation/Update/Deletion.
- Receipt Creation/Delivery/Advanced Shipment Notification.
- Invoice Creation/Consolidation/Updation/Deletion.
The diagram depicts integration of supplier interface using SFTP connections between Ivalua and SAP.
SCENARIO – II
Ivalua Integration with SAP S/4 HANA using Web Services
To support the SAP and Ivalua integration, interfaces were designed and constructed to ensure that the information and data is exchanged timely and accurately between the two systems.
Following (Both to and from SAP S/4 HANA ) touchpoints were considered:
- Supplier Creation/Changes/Extension/Block.
- Requisition Creation/Update/Deletion.
- Purchase Order Creation/Update/Deletion.
- Receipt Creation/Delivery/Advanced Shipment Notification.
Integration was established using the Process Orchestration tool from SAP side and creating EAI in Ivalua.
Using real-time web services enables us to reduce the number of interfaces. As the synchronous response can be utilized to exchange information about the document created in the receiver system and send it back to the sender system.
Above diagram depicts an example of supplier interface and the data exchange between systems using web-services.
Problem VS Solution
For easy understanding, we refer to the various combinations as defined in the interfaces matrix below. The matrix explains the situations in which the combinations are used.
|
|
Let us also understand how the above mentioned methodologies and design models compare to each other and the USP they carry. This helps in making the right decision for our projects:
REST vs SOAP:
- SOAP is extensible and supports multiple web service expansions. SOAP supports distributed integrations across systems yet, writing XML requests requires meticulous programming skills.
- REST is easy to implement and is designed for point to point communications. It supports multiple formats for payload files and supports built in error handling.
JSON vs XML:
- Although, at the first look JSON looks perfect for exchanging data utilizing lesser memory, supporting multiple browsers and being easily readable. But, when it comes to exchanging data utilizing a variety of data types and with multiple encoding formats support, XML is the preferred option.
Conclusion
Having analyzed the different methodologies and models available along with an understanding of their pros and cons, we establish certain key factors that should be considered for a sustainable P2P interface and these factors help us make the right selection of the design and data models for our integrations.
| Factors considered for a sustainable P2P Interface | Applicable to SFTP | Applicable to Web-services |
|---|---|---|
| Interface Necessity for Business:
This is the primary driver of an Interface design project where we have to consider what Interface is in question and what will be the priority/importance of the Interface on the day to day activities of a business process. Interfaces can be real time to immediately synchronize data, Or asynchronous when data is in bulk and frequency of exchange is lesser. |
If the frequency of the sync is intended to be in batches and the size of the file is in megabytes, then SFTP mode should be preferred | If the frequency of the sync is intended to be real-time and the size of the file transmission is in kiloBytes then webservice mode should be preferred. |
| Technology is available:
This is yet another influencer in determining the mode of Integration as not all technical options (like firewall setups, SFTP hosting spaces etc.) may be available and will need to be considered in detail before reaching a conclusion on the Interface. |
If an organization already has the SFTP server being maintained and resources already available for building the interface, then SFTP is a definite option to be considered and yet the frequency of sync can be made near real time. | If the organization does not have any SFTP servers maintained, then starting off with a REST based web service would be a good option, the development is really quick and almost all the applications like on-cloud/on-premise support REST protocol. |
| Timelines and Skills shortage:
The best way to handle this will be to make use of already developed interface structures. Maximum effort during a project phase would only be limited to deployment, thus saving on timelines and resources. |
Based on the above two factors and also considering the timelines of the development, SFTP would be a quicker option. | Web Service technology would require some additional level of development skills.However, design using REST services supports feasibility in terms of quick development. |
| Past history:
Previous working history of the team being engaged and the list of interface objects being planned for the project. |
SFTP is a better option if the engaged team has more experience around SFTP setup and security aspects | A better choice if the team has experience of building integration objects based on web-services |
| Size of transmission:
The size that is being transferred from source to destination does have an impact on the mode of Integration considered |
It is a chosen option if size of data being transferred is more and the frequency of the transaction is less | It is a chosen option if the frequency is more and size of data being transferred is less |
Prasanth Babu
Director – Technology