Clarity Service Management

SDM to 3rd party tool integrations... what if...

By Michael_Mueller posted 06-24-2017 02:56 AM


Involved in various 3rd Party product integrations from and to SDM in the past, I started to think about a whish list, which would make life easier and cheaper.

Most People are aware that SDM has very strong and rich inbound API's (SOAP & REST based),while it has a lot of weaknesses when it comes to oubound communication capabilities.


So here is my whish list:

  • What if SDM would be able to send out HTTP(S) requests based on Transactions( data record changes), natively, without the need of any external tool, supporting SOAP and REST based API's.
  • What if these http requests would be configurable and testable through the normal SDM GUI.
  • What if the HTTP requests could easily incorporate data from the context object( the record which was changed).
  • What if the response of such an HTTP request could be evaluated and a result could be written back into the context object (changed data record) itself.
  • What if you would be able to define so called webhooks, which defines the event and trigger conditions for an outbound HTTP communication.
  • What if these webhooks could be defined for any factory (object type).
  • What if these HTTP requests could be send out
    • synchronously, as part of the transaction, so that an error which may occour in the HTTP communication would abort the transaction (Save) and present the user with the error message
    • asynchronously, executed after the "Save" in the background, so that the user would not be harmed by any communication error.
  • What if failed asynchrounous HTTP requests would be automatically repeated if they have a technical error reason (timeout/connect failure due to network outage or Service unavailability) in the order they were submitted.
  • What if you would have a complete history of the HTTP communication, to be able to  check and comprehend what is and was going on.


Let me know , if you think these capabilities would be useful/helpful in your integration challenges as well.

And let me know, if you have additional ideas / whishes / comments.


Kind Regards




07-20-2017 12:27 PM

Hi Lindsay.

Thanks for your comment. I have made the same expirience regarding expectations in integration projects.


My current approach tries to find some generic ideas/solutions for recurring todo's. I'm quite aware, that each and any kind of integration framework has also limitations.
But if we would have something available which maps somehow to this whish list, we may be able to harmonize 60-80% of integration implementations and reduce implementation efforts a lot, because we don't need to reinvent the wheel each time, but for sure, it might not fit to each and any requirement.

It is my inner belief that such a kind of a http based communication framework will make life much easier for all of us (customer/partners/services).
So don't worry, I'll be keen on this stuff a lot, and wont let it go


Best regards


07-18-2017 01:29 PM

Hi Michael,


I like your wish list and hope that at least some of it can be incorporated into a future release.


There are always challenges with integration. Whenever a client has asked me if Product A from Vendor ABC can integrate with product X from vendor XYZ, my first question is "How would you like them to integrate?". The response usually comes out to be "in any way I can imagine now or in the future".


I encourage you to keep this moving forward.




07-17-2017 04:53 AM

excellent comment mderidde, thanks for this input!


Your first idea is, at least in my understanding , a typical follow up to the original ones.

Exactly, as soon we may have the basic outbound communication capability, we would need some kind of mapping functionality between internal and external values.
I would like to enhance this one a bit, additionaly to the  capability of field value mappings of course for inbound and outbound communication, I would like to have a generic ability to store the mapping between internal and external primary keys of shared objects. Maybe similar to what we already have for CI's (mdr's and federated ci mapping)


Your second approach is of course a more complex one, nevertheless, one which would make life easier for others

Let me explain what I mean.


Integrating systems nowadays is often a bidirectional one, so two systems have to "talk" to each other.
And as in communication between people, both systems need to be able to listen(inbound) and talk (outbound).
While it would be great if all products would speak and understand the same language for conversation with other systems, this isn't the case. In fact all products using their own proprietary languages(API's).

That means if one system (A) needs to talk to another system (B), you have two choices:

  • System A learns talking(outbound) the native (proprietary) language of system B
  • System B learns to understand(listening/inbound) the native (proprietary) language of system A.

We might be able to implement the first one with the ideas above.
Being able to also learn foreign API's (Inbound for SDM) as you suggested in your second idea, would open up the most flexible aproach, when it comes to bidirectional integrations.

A 3rd party partner system would then be able to talk in his native proprietary language to SDM, and that would make life easy for this 3rd party product.


As always, comments/ideas/thoughts are more than welcome.

Kind regards


07-12-2017 12:52 AM

One more from my own experiences with integrations:

- What if there were a way to define mapping tables containing values to be used to/from SDM to/from the external 3rd party tool we integrate with for any attribute.


And maybe one more as quite some tools start having all the above but then sometimes lack this one:

- What if we could define/create our own inbound web service methods to front-end the integration from the 3rd party vendor into SDM which would have the added benefit that we could chain several calls together (e.g. login, several lookups using the data from this custom front end WS and then maybe a createRequest using all returned data together)