When selecting a new, best-of-breed automation solution for the purchase-to-pay process, the topic of interfacing comes up fairly quickly, especially with the advent of SaaS. What does a migration to the cloud mean for interfacing with the ERP system? What considerations are important for an IT department?
At ICreative, we regularly get questions about what methodologies of interfacing with ERP we use. Especially with the advent of SaaS applications, interfacing and data security are important issues. Understanding the considerations that are important to an IT department can help speed up the implementation process.
On-premise versus Saas
Indeed, in an on-premise situation, the ERP system, financial system and purchase-to-pay (P2P) application are all in the same IT landscape. That makes it easy to set up an interface. A direct link is possible and you have it all under your control.
With the advent of SaaS, the issue of how to place a best-of-breed application, such as Basware, in the architecture arises. We now suddenly have to conform to the protocols of cloud solution providers, many of which are standardized. That gives a lot less freedom. In addition, the transport also has to be over the Internet. Companies without in-house knowledge or tools have quite a bit to manage.
Synchronous versus a-synchronous
When we talk about interfaces, what are we really talking about? Interfacing means integrating data across multiple systems and applications. In order for the different systems to talk to each other, the so-called providing party makes data available to the requesting party that consumes the data, so to speak.
The link between two applications can be direct or indirect, either synchronous or a-synchronous. In the latter case, multiple transactions are required to send data from one application to the other. For example, the transport of the data is through an FTP server or fileshare. The disadvantage is that there is less control over whether the data actually arrived at its destination (the ERP). If the link is synchronous, then you have an immediate answer as to whether the import was successful. However, we see in practice that links between ERP systems and P2P systems are very often a-synchronous.
Example a-synchronous interface
In this example, the interface is asynchronous and the ERP system does not know if the data has actually been imported. Source: ICreative (2020)
Authentication
An important factor in integration is authentication. This means that the delivering party must give permission to the requesting party to use the interface. This can be done in several ways. For example, authentication can take place via a username and password or, for example, via an agreed secret key (a so-called API-KEY). A more far-reaching form is, for example, an Active Directory integration or VPN connection. This allows the requesting party to communicate directly with the supplying party's network.
Legacy, API and web service
When we start looking at the technology behind the interface to be constructed, a distinction can be made between legacy interfacing and modern interfacing. Legacy interfacing is customized for each application and therefore often not reusable. This is usually only possible when interfacing between on-premise applications.
Modern interfaces work with what is called an API or Web service. Every Web service is an API, but not every API is a Web service. How's that? API stands for Application Programming Interface. It includes a set of programming instructions and protocols that can be used to exchange data. From one application, you then use a piece of code from another application. An example of this is when you make an appointment with a Microsoft Teams or Skype invitation from your mail program Outlook. This goes directly from one program to the other and does not cross the Internet.
So a Web service is an API that can be accessed over the Internet. That makes a Web service extremely suitable for cloud applications. The connection is synchronous, which is very nice for exporting invoices, for example. Moreover, Web services are often documented, which allows developers to more quickly adapt the software that calls the Web service accordingly.
Web service API documentation
A common way to document Web services is through a so-called swagger definition (method of documenting and using REST Web services). This definition can be published via a Web page so that the developer can get started right away.
The example shows a swagger Web page from Basware, describing two different Web service with their calling methods:
SOAP and REST
Within the domain of Web services, there are roughly two protocols: SOAP and REST. Microsoft developed SOAP (an abbreviation of Simple Object Access Protocol) in 1998 as a way for external machines to talk to each other in a standard, coherent way over the Web. REST (an abbreviation of Represention State Transfer) is also considered the successor SOAP. REST offers more freedom and flexibility in setting up Web services compared to SOAP.
The major advantage of SOAP is that it is not tied to HTTP(s) as the means of transporting the data. As indicated earlier, this allows the requesting party to validate directly whether the messages they send are correct. Especially if you work with a huge number of diverse (complex) services that are only used internally, SOAP is handy.
The reason many programmers go the way of REST is because it makes more sense. It works easier and it saves time.
JSON and XML
Related to the chosen Web service protocol is the data structure. SOAP has XML as its only option. This is easy to set up and has the advantage that metadata can be included in the message itself. REST supports multiple formats and works very well with the "lighter" code JSON (JavaScript Object Notation). This results in better performance and higher speed of data exchange. It is ideal for Web sites that use JavaScript, since JavaScript itself is built from JSON.
Only after it is clear which protocol will be used and what the desired data structure is between the servers can the Web services start exchanging information among themselves.
Be prepared
In short, there are quite a few things that need to be taken care of. It is therefore advisable to involve the IT department at an early stage and think about the interface. This ensures that internal systems are organized and structured in such a way that new P2P projects can be supported in a uniform way and will have a shorter turnaround time.
We see that companies with in-house IT departments are often equipped with interface tools. For companies that do not have domain expertise or appropriate tools in-house, this can hurt the turnaround time of a P2P implementation. In this case, a good implementation partner can provide assistance.
>>View how ICreative can help here