You might wonder, what kind of scenario in an integration would require a delay in the messaging logic? I can open up a scenario where with Service-Flow you can do a little bit of magic with only some minor configuring of the integration rules.
There is a typical scenario in integrations that the ITSM tool sits behind an ESB. This then means that the syncronous response to Service-Flow will usually only include some technical validation of the message structure etc. At the same time, some ITSM tools tend to have feature where it locks a ticket that is currently open on a screen. All this would then create a possibility to the following scenario: Ticket is opened on the screen of a technician, when an update is sent to it via integration. The synchronous response from the ESB will say "ok", but after a while an asynchronous ack message will say "well, actually even though we earlier stated that the message was ok, it actually wasn't". Awkward situation, right?
Well, with combination of conversation attributes and some delay logic, you're able to do the trick. First, to the update rule that originally is triggered, add conversation attribute mappings for all the elements that you would need to resend in the case the asynchronous error ack is received. Then create a new rule that routes the error ack message back to the system that it was sent from, if the particular error is received. Instead of using the message elements to map values into the outbound message, use the earlier mapped conversation attributes to build "the same message again". In addition to this, you can add e.g. 60 second delay before the "update" is tried again. You are also able to configure a conversation counter to track the amount of retries you want to do. You can also make a rule that is matched when this counter exceeds certain value. All these things combined you are able to do the following in example: When update is sent to a ticket while it is locked in the target system, there will be a maximum of 10 retries with 1 minute interval. After ten failed attempts, a message to the source system is sent posting a comment "Update failed to reach the target. The target ticket is locked. Try again later", to inform the person that originally sent the message.
Service Flow has brought a concept of conversation to ITSM integrations. Conversation is an overview of a single tickets lifecycle between all connected endpoints. This view helps the administrators to rapidly see how, when and by whom the ticket has been updated.
Usually when integration is built, it is mainly developed to relay messages. That means that mappings and translations can only be done with the information that the updated message includes at the time. With conversation attribute we at Service Flow bring “a memory” to your integration.
Let me give you a typical example.
Let’s assume that a company A has outsourced its SAP support to Vendor X. Company A’s support receives a ticket that a user is unable to print from SAP system. Ticket is assigned to a local support team and local support visits the user’s desk to check the printer. No solution is found so the support person assigns the ticket to SAP support that is handled by vendor X. Ticket is created to vendors system via integration and automatically assigned to a correct group. Now the vendor after an inspection wants to assign the ticket back to the group that it was originated from. Typically that info is not anymore present in customers system nor is it stored to vendors system. So how to solve this?
What if every time customer assigns a ticket to a vendor, we would save the original assignment group to a conversation attribute in Service Flow? Then when vendor assigns the ticket back, we could use that value in the update to be able to assign the ticket to the original assignment group in Customer A’s system. Easy, Simple, Understandable. Right?
And this all by configuring. Naturally… ;)
In practice, all SSL communication between Service-Flow and the systems that it integrates to, happens by using TLS protocol. A vulnerability in the design of SSLv3 protocol has been found that makes it possible for man-in-the-middle attacker in the vicinity of the client (i.e. in the same WLAN network) to downgrade the SSL traffic to use SSLv3 instead of TLS. Then, using some sophisticated techniques, he can gain access to client's session cookie and access his web applications with the client's credentials. This vulnerability is called POODLE (Padding Oracle On Downgraded Legacy Encryption).
The POODLE vulnerability is rather theoretical in the context of Service-Flow integrations between systems, but as it's more probable when connecting to Service-Flow's UI through a web browser, we're taking necessary measures to remove support for SSLv3. Service-Flow is moving to a new infrastructure in the near future and there, SSLv3 will be completely blocked. The move will be done during December.