In June of 2006 Google launched the google maps API allowing Java Script developers to put Google Maps on their own websites.
Few other companies had or have the resources to tackle mapping the world, let along making that available via an API. Google Did! While not the first to use APIs on the web, SalesForce can take credit than in 2000. Google has since exposed thousands of APIs for free and at low cost to companies the world over.
Googles own Maps Application utilizes their own API. Similarly, the Acumatica App uses the Acumatica Mobile API.
When a desktop user logins in to Acumatica and looks at a Vendor or Customer record they have the option to validate the address or display the address this is done via a configurable set of code that can point to Google or Bing Maps APIs or even use Avalara’s Tax API to check address and postal codes. Without these APIs this functionality would not exist, and we’d spend our time manually validating postal codes via web searches, paying for high dollar reports or digging thru phone books.
Let’s talk about 3 common ways to design an integration to Acumatica
In these examples I am using the popular Marketing Site Constant Contact. Constant Contact provides a variety of APIs for managing Contact information and using that information to build mass marketing emailing campaigns and constructing in-house and customer surveys.
shows adding the application code to Acumatica’s native language. Acumatica is well suited to do this via its customization’s suite. This could take the form of an additional button added to a form like our Validate Address example earlier, be completely hidden from the end user, or even be a fully standalone new form added to Acumatica just to handle this process. This new Acumatica code could then push or pull data from Constant Contacts API.
shows creating a standalone application to handle the translation of data and the push or pulls between the two systems APIs. Depending on the intended process, the application contacts the Acumatica Marketing API to retrieve or send data. It then uses a send or retrieve data operation to complete the process with Constant Contacts Email Campaign API. Or Vice Versus as the situation requires. The important thing to note here is that the middle-ware could live on a single employees PC, multiple employees PCs, a network server with internet access, or even on a cloud server with access to the Internet.
shows the application code living inside the Constant Contact program. The Constant Contact API is never used in this example, only the Acumatica API is pushed to or pulled from. Many companies have code that is ready to connect to Acumatica APIs with minor configurations.When designing integrations, we need to keep in mind that this may also be in existence. In this example Constant Contacts development team would have recognized the need for an integration point to Acumatica and created it using Acumatica’s APIs. Another possibility is that the non-Acumatica program may have customization tools available like Acumatica’s. Zoho CRM is one such case I have run into recently. The design choice here than becomes a matter of which has the most robust tools and which presents the better ROI to develop in.
When talking about processing signals from APIs we often use the terms Polling or Pulling, this an application connecting to an API seeing if the expected conditions are met and then acting. This was first method developed but is rarely the best method.
Pushing also called Web hooks, this is when an application registers a URL with an API. The API then pushes data, a notification, to that URL when the expected conditions are met, the event. The application recognizes the change in the URL and then acts. This is the preferred method, especially in long running operations or when operations are asynchronous. That’s to say,not performed in a specific order.
Web Sockets are just starting to gain usage in the API world. Here the applications maintain a handshake connection. Only when a requested event occurs will a notification be sent along the connection. The advantages of Web hooks apply here as does the ability to register and unregistered requested events along the open connections. While possible with Web hooks this is more elegantly handled by Web Sockets.
There are 3 or 4 integration options depending on how you want to break it down. This doesn’t include the 5th API for the mobile application which is out of the scope of these videos.
The first of these options is O-Data. Initiated by Microsoft in 2007 O-Data or Open Data Interface is a standard protocol for sending XML data across the web via XML. Acumatica uses O-Data to share Generic Inquiries, a term for customized data queries, to programs like MS Excel and Power BI.This format allows for sharing data only and not for making changes to the Data in Acumatica.
The next option is the SOAP Screen Based API. This option uses SOAP standard to import, export data and to perform actions in Acumatica. The screen-based API uses a sequence of Objects and Commands in the same sequence that an end user could perform those actions from the UI. WSDL is the web service standard used to in a Visual Studios project to employ this API. Caution applications using this API may need to be updated when upgrading Acumatica.
Options 3 and/or 4 is the Contract Based API. These options use either SOAP or REST standards to work with Entities, Fields, and Actions in Acumatica via Endpoints. Endpoints are defined by the WCF service and tend to be more stable, as they utilize versions to track the changes to the API. Endpoints also offer the ability to be customized in order to add additional fields from an upgrade or from a customization made to the native code via the Customization Suite of tools.
View the other videos in this series
