Sample code for business rule - sending additional comments ONLY to another SNOW instance using the REST API

motto · ‎05-16-2020

Hi Everyone

I appreciate everyone's help in advance, I can really use it.

I am a novice developer seeking some assistance on the creation of a business rule for sending work notes between ServiceNow instances.

1) On instance 1, I need the business rule to validate and leverage the correlation ID in an incident being updated to inform Instance 2 of the Incident that needs to be updated on the Instance 2 side

2) On instance 1, I need the business rule to capture ONLY the additional comments (not the work notes) to send to instance 2

3) I need instance 1 to send the updated additional comments from instance 1 to instance 2 to the corresponding incident based on correlation id.

Some conditions:

1) I would love a complete code sample - one that is known working with the above or at least part of the above in mind. In fact, this would be optimal. Sending links to other references is not optimal, as I am trying to piece this together. While I am working actively at furthering my development knowledge and skills, I am a novice.

2) I have been attempting various combinations leveraging the scoped GlideElement for getJournalEntry (https://docs.servicenow.com/bundle/jakarta-application-development/page/app-store/dev_portal/API_ref...) with no success.

3) I have attempted the activity through IntegrationHub, which I am receptive to using, but while parsing the ticket, I am having difficulty acquiring the respective journal entries. If anyone has a complete flow use in Flow designer and integration hub that accomplishes all of the above, I would be grateful.

Thank you all

motto · ‎05-19-2020

Absolutely! I am writing a more definitive guide for my own sake that I will post later on. My experience in integrating platforms over the last week has run me through a number of scenarios.

I offer the following to ServiceNow, before I share (skip to the bottom for my link)

I don't consider myself a developer per say. I spend way more time on the site reliability side of things working with tools like Terraform or Ansible. These tools leverage common known methods of accomplishing their functional tasks for integration. In the case of Terraform (for those who don't know - a tool used to deploy and destroy infrastructure in various cloud and private cloud environments like AWS, Azure and vsphere using code) they have pre-built "providers" which you hand variables to in a YAML file to tell the cloud environment what you want the new infrastructure to look like - e.g I would like 3 new EC2 instances, 1 load balancer, etc.

Why is this relevant?

Amazon, Microsoft, VMWare have all made it straight forward to leverage their API - with Terraform again as an example, you use a YAML file to describe a configuration you would like, ensure the correct keys are in place, and it works. Very rarely does it require that you have to write any code (as in custom Javascript). Multiple integrations scale very easily. In my experience, ServiceNow has not made this effort straight forward at all. By the way, the community is amazing - especially the slack channel!

1) As a partner, and as someone who has to step in to solve customer integration issues because a key resource who did this work previously left, I just experienced what customers say to me all the time - the platform is great when its understood and works...otherwise, it almost always requires some custom development to get simple things operate as you expect them to. This is going to make marketing folks squirm, but ServiceNow is its own barrier to entry with customers. The price of this platform should ease the burden of this type of work, not force a learning curve that can't be resolved in a couple of hours.

For those of you who are new to integration, my experience is as follows:

2) ServiceNow, recognizing this, has made an effort to eliminate some the complexity through FlowDesigner, IntegrationHub with REST extensions and the ebonding spoke. I got all of these working, and they are great - out of the box - If you have the need to integrate ONLY with ONE other instance.

My customers are communicating with multiple instances, and their scenarios are varied. To get FlowDesigner working correctly with more than one instance, I had to build another app and custom code script includes.
This itself is also limited - it assumes that everything works based on table updates - there are many scenarios that require the creation of UI Action as an example that will, on click, make a REST call and update records

Ultimately, I abandoned flow designer, and went back to simple business rules and UI Actions to accomplish my objectives there are many scenarios for integration that need to be expanded on. I am working on it, because in fairness, its easy for me to say something needs improvement, and not offer a solution. In the meantime, I offer the community the following solution, where I created a UI Action to send incident updates on click.

setRequestBody won't POST unless manually defined

This solution assumes:

1) You have created the correct REST message and target to POST an update

2) That you understand how to modify the associated Javascript needed to select the correct fields to send.

Thanks all

View solution in original post

Community Alums · ‎05-19-2020

Hi Motto,

Would you like to share the flow you've created so far and the community can then help you learn how to correct it?

It sounds like you've already got the REST/SOAP message bit sorted (or are you using the ServiceNow eBonding Spoke)?

Cheers
Mike

motto · ‎05-19-2020

Absolutely! I am writing a more definitive guide for my own sake that I will post later on. My experience in integrating platforms over the last week has run me through a number of scenarios.

I offer the following to ServiceNow, before I share (skip to the bottom for my link)

I don't consider myself a developer per say. I spend way more time on the site reliability side of things working with tools like Terraform or Ansible. These tools leverage common known methods of accomplishing their functional tasks for integration. In the case of Terraform (for those who don't know - a tool used to deploy and destroy infrastructure in various cloud and private cloud environments like AWS, Azure and vsphere using code) they have pre-built "providers" which you hand variables to in a YAML file to tell the cloud environment what you want the new infrastructure to look like - e.g I would like 3 new EC2 instances, 1 load balancer, etc.

Why is this relevant?

Amazon, Microsoft, VMWare have all made it straight forward to leverage their API - with Terraform again as an example, you use a YAML file to describe a configuration you would like, ensure the correct keys are in place, and it works. Very rarely does it require that you have to write any code (as in custom Javascript). Multiple integrations scale very easily. In my experience, ServiceNow has not made this effort straight forward at all. By the way, the community is amazing - especially the slack channel!

1) As a partner, and as someone who has to step in to solve customer integration issues because a key resource who did this work previously left, I just experienced what customers say to me all the time - the platform is great when its understood and works...otherwise, it almost always requires some custom development to get simple things operate as you expect them to. This is going to make marketing folks squirm, but ServiceNow is its own barrier to entry with customers. The price of this platform should ease the burden of this type of work, not force a learning curve that can't be resolved in a couple of hours.

For those of you who are new to integration, my experience is as follows:

2) ServiceNow, recognizing this, has made an effort to eliminate some the complexity through FlowDesigner, IntegrationHub with REST extensions and the ebonding spoke. I got all of these working, and they are great - out of the box - If you have the need to integrate ONLY with ONE other instance.

My customers are communicating with multiple instances, and their scenarios are varied. To get FlowDesigner working correctly with more than one instance, I had to build another app and custom code script includes.
This itself is also limited - it assumes that everything works based on table updates - there are many scenarios that require the creation of UI Action as an example that will, on click, make a REST call and update records

Ultimately, I abandoned flow designer, and went back to simple business rules and UI Actions to accomplish my objectives there are many scenarios for integration that need to be expanded on. I am working on it, because in fairness, its easy for me to say something needs improvement, and not offer a solution. In the meantime, I offer the community the following solution, where I created a UI Action to send incident updates on click.

setRequestBody won't POST unless manually defined

This solution assumes:

1) You have created the correct REST message and target to POST an update

2) That you understand how to modify the associated Javascript needed to select the correct fields to send.

Thanks all

Runjay Patel · ‎12-20-2020

Watch this video for Slack integration steps by step configuration. Post message on slack channel via flow designer.

https://www.youtube.com/watch?v=YEGLJLubCCY&t=1s&ab_channel=ServiceNowHelpdesk

Please mark reply as Helpful/Correct, if applicable. Thanks!!