References:
step by step guide:
https://exalate.com/blog/servicenow-ebonding/
sending attachment OOTB methods:
other references:
https://www.servicenow.com/community/developer-articles/ebonding-servicenow/ta-p/2312922
https://www.youtube.com/watch?v=4hBpkX5XJcA
apparently the following are supported:
- OAUTH
- attachments
if not visible in the plugins list you may need to request it on the instance via Support Site:
Procedure:
set up the auth credential
set up the flow designer
error handling (e.g. other ServiceNow instance down and transactions need to be re-queued):
You can build error handling into it, write into logs, send notifications, create tasks, even add timers to retry it later https://docs.servicenow.com/bundle/rome-servicenow-platform/page/administer/flow-designer/concept/flow-error-handler.html
Video version: https://www.youtube.com/watch?v=eAyifOmQ-DY
--------
further questions answered:
- Concatenation of multi source fields to the same target field (for example, we propose mapping description, configuration item, category, subcategory and to the target instance description box) [] there is one action to retrieve data, and another one to update the ticket, using the data pills you should be able to concatenate them any way you want.
- Data lookup: for service offering, the value we send to the target instance may not correspond exactly and hence an internal lookup on the target side will be required to determine the target service offering [] I would recommend using IntegrationHub ETL (or just plain RTE) to match and transform SO values to your instance.
- All of the various use cases we have in scope: create, update, resolve, reopen from resolve. Field maps will be different per use case so I assume a separate sub-flow will be needed per use case? [] update, resolve, reopen could all be if statements with an Update Remote Incident flow. You could also build them as subflows and call them as needed so it’s more maintainable.
- 3rd party references will need to be preserved (if for example source instance sends a ticket already eBonded to another system to target instance, we need to preserve our original correlation_id > I think we may be able to overcome this by storing the target instance number in a dedicated field. I am assuming eBonding solution returns a REST Response to the originating system which will contain the counterpart incident number, and we’ll be able to process this response and store its values in the fields we choose to? [] by default it uses correlation id, but you could have your own dedicated field. It does send a REST payload and you can transform it any way you want it.
- We have a requirement to close the bond for certain use cases as a ‘fire and forget’ (for example, a use case we’ve identified is ‘created in source instance in error’ which will be a fire and forget after which we close the source ticket following handshake from target instance) So we’ll need to ensure that updates from target to source are blocked if the source instance ticket is already closed – although we’ll need to store the target number [bfs] Not even comments/work notes? It’s something you can very easily configured if needed.
- We also have a requirement that if an eBonded
ticket on the source instance side is updated to set it to security incident=true,
we need to immediately close the bond and send a close/cancel transaction
to target instance. Again I presume that’s a separate subflow for that use case? [] It is bad practice to manage security incidents in
the same table/scope as IT incidents as it can lead to many more security
incidents itself, but you can have the same type of validation for “fire
and forget” for “security incident” to close and block updates.
(note this security incident true/flag was just a particular implementation by the client and is not necessarily best practice)
(ServiceNow )
Comments
Post a Comment