In this post we’re talking about BMC Remedy integration. Recently we worked with a tech non-profit to integrate their back and front office systems. This included:
- Ensemble and Cache as a central database
- CRM Dynamics containing historical and ongoing sales and marketing data
- A bespoke web portal for processing data and requests
- BMC Remedy for call centre management
Being a company which lives and breathes IT integration, this is a fairly typical project for us. Over time we have developed our expertise in integrating various applications and we have a solid understanding of the multiple quirks inherent in these.
Are you thinking about integrating your company applications?
From time to time we share some of our integration top tips, and we picked up some useful tips with regards to working with BMC Remedy* which we thought we’d share.
1. It is essential to use simple service definitions
Remedy does not handle complex WSDL service definitions very well. So in order to develop an integration in which Remedy accesses another system’s web service, it is important to provide the Remedy team with a WSDL that does not reference external XML schema files, for instance.
XML elements that reference themselves (e.g. to represent a hierarchical structure) cause difficulties, with Remedy only being able to send the top-level element.
A good practice we recommend in terms of SOA governance, is to define standards that all services should aim to comply to. You can still have the target system expose a complex WSDL (referencing external schema files, for example) but generate a simple WSDL that is compatible with that one, just for Remedy to import on development phase so that it can generate its’ client components based on a all-in-one WSDL file.
2. Remedy services are not truly synchronous
Remedy exposed services’ default behaviour is to validate the request message and, in case it passes validation, return a success message even before committing the database transaction.
This means that a system that makes two subsequent calls (usually with a difference of just milliseconds) to Remedy services, one writing data to its database and the second one retrieving the same record, may find on the second call that the data has not actually persisted yet.
In a complex environment with tens or hundreds of calls per second, this may cause unexpected errors to the end user.
One option in that case is to have Remedy access another service when data has really been committed.
3. It is preferable to create and update via a single service
As with most systems, it is highly recommended for Remedy to expose a single “save” service operation per entity as opposed to having it expose one “create” and one “update” operation.
Apart from helping with the problem described on item #2, this allows for Remedy services to be able to be invoked from multiple systems (ideally via an Enterprise Service Bus) without one system having to know whether the other has already created that record or not.
That also removes complexity from the client system(s) making Remedy responsible for deciding whether to create or update the record.
4. Don’t be afraid of authenticating
Remedy services can indeed require authentication although it usually does not comply to the WS-Security standards.
Client system(s) may therefore need to send a special SOAP header containing the username and password, for example:
<soap:Header>
<AuthenticationInfo>
<userName>myUser</userName>
<password>myPassword</password>
</AuthenticationInfo>
</soap:Header>
As a web service client, Remedy is able to authenticate to WS-Security-based services.
5. Be careful with workflows
Remedy workflows are a feature that is commonly put in place for users to follow a specific business process but when they are triggered by web service calls to Remedy, they may end up harming the service performance, causing delays and making requests time out.
6. Remedy is configuration-based
As Remedy administrators are usually tied to the Remedy configuration interface, it’s usually not easy for them to implement complex pieces of logic as one would do with imperative programming languages.
We like working with BMC Remedy because…. But it can be very useful to know the intricacies of the system to avoid pitfalls, and save development time and money.
Does your company use BMC Remedy?
This is just one of the many applications we work with on a regular basis. We had some feedback from one of our clients recently that by employing us as their integration experts, they saved employing three full-time integration developers on the same project. This is because we specialise in IT integration – you don’t need to develop your own integration experts, as we can do it for you.
A typical project might include:
- Process improvement and full integration audit
- Architecture, design and review
- Project delivery
- Integration testing
- Training and mentoring
- Solution support and outsourcing
Contact us to find out if one of our solutions would work for you. We have expertise across Financial Services, Healthcare, Public Sector, Retail and Utilities.
*Note – we are referring to BMC Remedy 8 in this case
Check back in soon to find out about integrating with Microsoft Dynamics.