ServiceNow IM,PM,CM and SRM Bi-directional Integration with vendor ServiceNow system via web-service

[SNOW46]

Hi All,

We want to perform ServiceNow to ServiceNow bi-directional web service integration for Incident , Problem, Change, and Service Request Management resp. 

As I am new to Integration respective, can anyone help me out as to what all criteria and what are the requirements needs to be captured to perform the Integration.I need to gather the requirements what all we need from the Customer End.

Also if there is any architectural diagrams required will help me out. Can anyone help me out on this how to achieve the same,

Thanks

[johnfeist]

Hi Snow@User,

What you are looking to do is known as eBonding.  ServiceNow has a very poor demo version of that available in flow designer which looks nice but doesn't meet the real world basic needs, at least as of New York.

What you are looking to set up is not a trivial effort.  There are a lot of moving parts to this.  The communications are normally done via REST.  If you are not familiar with using REST, Chuck Tomasi did a very good lesson on that.  Here's the link to the Scripted REST API lesson.  Basically you need to determine:

• How will objects be assigned to the sharing, assignment group, some part of the category structure, some other field.
• What data elements get sent and under what conditions.
• In most cases you will also need to consider sending and receiving attachments to whatever objects are being created.
• If you are building this as the customer and not the support partner, what assignments go to what partners.
• With this information, you can start building your scripts.  Typically, they will start with BRs.  If all the objects extend task, that's the best place for the initial BRs.

As far as sending:

• You need to instantiate your REST message
• Build the package
• If this is about an existing share don't forget to include the correlation data
• Build out the full message
• Send the message
• Receive the reply which will tell you if you were successful, in which case you may need to populate the correlation_id and or correlation_display on your record
• If you were not successful, take appropriate action

As far as receiving

• Again, if building from the customer side, you will be the originator of all object shares.  If you are building from the support provider side, you need to be able to handle both new and updated records.
• You need to have a landing table where your inbound data will come as well as transform maps to apply the data appropriately.
• Have a scripted REST API that will handle your incoming data and send the appropriate reply.

I recently did the build/implementation of our eBonding with a lot of help from our support partner.  There are a lot of little "gotchas" along this path, so be sure to spend the necessary up front time in terms of understanding requirements, mapping out processes, etc.  One other thing that people often forget is that you will need two ServiceNow instances to do any testing.  I used my PDI as the partner so that I would be able to test successively from dev, test and prod.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster

[SNOW46]

Hi,

Can you let me know in details as to what all expectations we will setup from the Customer end,what all pre-requisites we will consider, what all things are required to perform the integration for Change Management.

This will also be bi-directional integration via web-services.

Thanks

[johnfeist]

That's a big ask. Consulting firms charge a lot for all of those details as there is a large volume of conditions to consider.

Change Request and Change Task both extend task so there are a lot of data fields that could be exchanged.  If you are the support partner, the first question is how involved will you be in the change management process as opposed to implementing the changes once they are approved?  In my experience support partners play a limited, if any role in the change approval process but play an active part in change implementation.

If you are going to set up for both, you need to consider who can change what.  Fields like state which are often shared for incidents and requested items are typically only shared one way since the client has to control when the states change.

The way that the client/partner relationship normally works for change implementation is that the client will create tasks for the partner to perform.  For these, the normal fields, short description, description, state, priority plus any implementation specific fields will be sent to the partner.  It is normal for these tasks to have attachments which must be available as part of the partner task.

Again, all of this is communicated bidirectionally via REST.  If properly configured your Scripted REST API is the landing point for all inbound packages and directs data into a landing table from which your transform maps handle inserts/updates to the relevant table(s).  Your Scripted REST API should also handle structuring and sending the reply which will typically contain a status code (these have been standardized) a status message, the correlation_id, correlation_display along with any error messages if errors are found.

If you are anticipating interacting with multiple clients, make sure that you build your package construction scripts with sufficient flexibility to handle differing requirements without the need for hard coding/custom code for each client.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster