It’s been a while since Remedy REST API is being introduced to the public. Yet it becomes a top contender to SOAP when we are talking about web based integration between Remedy with some other 3rd party application.
It’s been a while since Remedy REST API is being introduced to the public. Yet it becomes a top contender to SOAP when we are talking about web based integration between Remedy with some other 3rd party application.This thing makes me wonder “Why BMC release 2 services that almost have the same capabilities within 1 application?”
After quiet sometime scratching my head and wondering “What is the difference between those 2 services?” I came up with several points that might be help you identify when or what to use.
REST API
Using REST API on BMC Remedy is like opening your restaurant kitchen to everyone and allows them to cook whatever they want, but still you are the one who control the list of ingredients or tools that can be used. On the bigger aspect the integration between Remedy using REST API is like head chef and his sauté chef. In this analogies Remedy act as sauté chef, it prepares all the key ingredients and let the chef cook it and present it to the customer.
As per BMC documentation, BMC have point out when you need to consider before you use REST API to integrate with BMC remedy:
· You need to access multiple BMC Remedy AR System components at the same time or integrate with programs or data outside the BMC Remedy AR System.
· You need to perform complex operations that involve multiple forms.
· You need a two-way interface (or gateway) between BMC Remedy AR System and another application.
· The values that you need to specify for $PROCESS$ or the Run Process action exceed the size limitation of the command line.
On some systems, for example, the command-line area for $PROCESS$ or Run Process parameters is limited to 256 bytes (expandable to 4 KB). If you use an API program instead, you can pass a parameter to an API program and manipulate larger-sized data within the program.
· You need to create reports or log files in a format that is not compatible with standard report writing tools.
· You want to create, modify, and delete objects.
We know that BMC Remedy has a server side rules which cannot be bend or change except by BMC Remedy Administrator/Developer. The only part that REST API skipped is the client side rules which means any application that interact with REST API is consider as a client application. What does this means? It means that the 3rd party application has a huge flexibilities how and what to send or get from BMC Remedy. The 3rd party application can create their workflow or business procedure then send it to BMC Remedy.
From the description above it looks like REST API is a great deal when you want to integrate with Remedy, but just like Uncle Ben’s famous quotes “with great power comes great responsibility”. REST API give you a whole new level of integration, but it also means someone have to code the workflow, implement the business rule, etc. By the words of “someone”, I’m pointing out either BMC Remedy Administrator/Developer or 3rd Party Developer (in some cases it require both).
SOAP
If REST API integration are consider as open kitchen where everyone can be a chef and Remedy will become the sauté chef, then in SOAP the relation can be consider as chef and waiters. The chef will tell the waiters list of foods that he’s able to make while the waiters will be the one who pick what to put on the menu.
Why did I come up with that? It because every time an application want to integrate with BMC Remedy, they have to ask BMC Remedy Administrator/Developer whether is there any endpoint available for this certain of actions or not. If not then they have to ask BMC Remedy Administrator/Developer to tailor up the endpoint for them.
Some people see this as a huge drawback on SOAP, but for me personally I won’t even consider to use SOAP to handle multiple or complex integration. I will use SOAP whenever it’s server to server integration or when it’s just a straight forward integration.
On their documentation BMC write:
“Web services provide a simple, platform-agnostic method for application integration. By using standard messaging protocols and service definitions to support computer-to-computer interaction over a network, web services allow application integration regardless of the hardware or software platforms and independent of the programming languages in which the applications are written.” – BMC (2013,February 11)
SOAP web-service allows you to talk with any apps on any level (except database tier) which means it gave you a huge range of integration. SOAP web-service also allows you to encapsulate multiple records into one transaction, so instead of having multiple transactions for each record you can use nested xml to accommodate it. The only problem is every time you want to integrate with Remedy using SOAP, then you should check it first either the endpoints is already there or not.