Highlighted
Honored Contributor.. Honored Contributor..
Honored Contributor..
617 views

how to handle connection timeout in Webservices integration

Hi Experts,
I need your help please.
We have integrated 2 systems (HPSM & external Application) using webservices & it's working fine. 
However sometimes there are some connection problems & the request does not get generated in the other system.
Has anyone faced this issue?  & how can we handle it? through Scripting? Does anyone has any script sample ?

Thanks

0 Likes
6 Replies
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: how to handle connection timeout in Webservices integration

What we've done for this is put a try/catch clause in the ScriptLibrary script that does the webservice call out to the external system.  If the response to the webservice call isn't successful, we write the contents of the call to the eventout table.  Then, we have a scheduler read the eventout table every X number of minutes and retry the call.  If the call fails again, it updates the eventout record.  If the call fails X number of times, we have the scheduler create a ticket to our team to get involved.

Depending on the integration requirements, we sometimes write to the eventout even if the result is successful, so we can have a copy of all the events we sent over to their side of the wall.  In other cases, once the result is successful, we delete the record from the eventout table.

The nice thing is, when it fails, you're able to see the contents of the call.  If the integration is down for some reason, you also end up with a queue of events as they occurred in your system, so when the integration is back up, you can just process the events in order to get the two systems back in sync.

Highlighted
Honored Contributor.. Honored Contributor..
Honored Contributor..

Re: how to handle connection timeout in Webservices integration

Hi Jacob,

Thank you for your reply.
I know i am asking too much, but can you help me with the script?  Is it possible to share the script?

Thanks

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: how to handle connection timeout in Webservices integration

Are you using SOAP or REST to talk to the external system?

If SOAP, did you use the WSDLtoJS function to generate the code for invoking the SOAP request, or are you generating the content of the SOAP request by some other means?

0 Likes
Highlighted
Honored Contributor.. Honored Contributor..
Honored Contributor..

Re: how to handle connection timeout in Webservices integration

Hi Jacob,

Thank you for your reply.
We are using SOAP (HPSM 9.30) & I generated the script using WSDLtoJS.

0 Likes
Highlighted
Honored Contributor.. Honored Contributor..
Honored Contributor..

Re: how to handle connection timeout in Webservices integration

Hi Jacob,
Can you please help me with this? 

"What we've done for this is put a try/catch clause in the ScriptLibrary script that does the webservice call out to the external system.  If the response to the webservice call isn't successful, we write the contents of the call to the eventout table.  Then, we have a scheduler read the eventout table every X number of minutes and retry the call.  If the call fails again, it updates the eventout record.  If the call fails X number of times, we have the scheduler create a ticket to our team to get involved."

I am doing my testing between 2 HPSM applications and I am using ServiceDesk service. (HPSM 9.30).
How do you create an eventout? and do you use smout (service management) event?

Can you please help me? I really need your help. 

Thank you

0 Likes
Highlighted
Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

Re: how to handle connection timeout in Webservices integration

Ok, if you're using SOAP and the WSDLtoJS, then you must also have created a second script (or functions within the first script) that translate your ticket to your SOAP request.  I don't have your script; I don't have access to your code, so you'll have to translate these examples to your system.

Let's pretend you are using the IncidentManagement module in HPSM, using the base WSDLtoJS to create a Script Librar script called IncidentManagement, and a second script, IncidentManagementInvoke, that uses the functions in that first script to query the system for an IM ticket, turn that IM ticket into a SOAP object, and invoke the call out to that internal system.

Within that IncidentManagementInvoke script, somewhere near the start, you're going to have a line that sets up your request Object variable; something like:

var request = lib.IncidentManagement.CreateIncidentRequest()

then you'll populate the details of that request object with your setValue() functions; like:

request.model.instance.Category.setValue("Incident")
request.model.instance.Area.setValue("Failure")
request.model.instance.SubArea.setValue("Function or feature not working")

and so on, to create your request object.

You _should_ have something like that already; none of that code you're already using to populate the request needs to change.

But, within that code, you've got some step where you're actually invoking the request; where you're actually using the 'invoke' method in that IncidentManagement script - something like:

var response = lib.IncidentManagement.invoke(request)

In that step, you're actually tossing the request Object you created and filled with values, and sending that using the SOAP protocol into the other system.  Now, that request is an Object - it's not a string, it's not an array, it's not an xml... to the JavaScript library, it's an Object.  And you can't save the contents of that Object into a string field.

So, what we did is, if the response is not successful, we translate that object into an XML string, using a function like:

var requestXML = new Object()
lib.SOAP.serialize(request, requestXML, false)
var reqString = requestXML.xml.toString()

Now, the reqString value is acutally a string representation of the SOAP request you've sent off over SOAP.  Then, we write that value into the eventout table.

We don't use eventmap or smout... we're just using the eventout table as a holding table for this data.  You could put it anywhere you want - you could make your own table for holding pending SOAP events; we just figured it made sense to use an OOB table.  So we manually populate the values in an eventout record.  We've got a function that creates an eventout record and puts the value of that reqString into the evfields field.

function createEventOut(reqString,IMNumber){
    var eventout = new SCFile("eventout");
    var retCode = new SCDatum;
    var nxtNumber = new SCDatum;
    system.functions.rtecall("getnumber", retCode, nxtNumber, "event")

    eventout.evsysseq=nxtNumber;
    eventout.evtype = "ExternalSOAP" // we usually name these to represent each integration
    eventout.evstatus = "Pending"
eventout.evtime = new Date(); eventout.evid = IMNumber eventout.evfields = reqString rc = eventout.doInsert() }

 

So, as I said, if the .invoke(request) wasn't successful, we call this function, and write the contents of the request into the evfields record of the eventout table.  You could (if you wanted) create an eventout record for all your successes as well.  You'd need to modify this function so that, instead of a status of "Pending", it would match whatever status of your call - like "Success" if your .invoke(request) worked or something like that.

In either case, the goal here is to save the contents of your request some place it's easy to get to later, and then have code that goes through these pending records and tries again.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.