How to read XML response from third party application , I am using xECM cloud 24.3

Nitesh harjai

I am trying to integrate the signing application just like docu sign ,

Step 1 :- I am authenticating with signing application getting a authorization token.
step 2:- I am pushing content server node( basically doc) to the signing application using rest client.
Step 3:- I will login to signing application GUI and sign the document.
Step 4 :- Signing application will send the XML response and now based on that response I need to push the workflow to next step ?

Any thoughts how it can be done ?

David Henshaw

Nitesh - are you trying to integrate with DocuSign, or something else that's similar?

Nitesh harjai

Hi David ,

Similiar to docusign not exactly docusign but.

David Henshaw

so it's just the finals step re advancing the workflow that you're having issue with?

I'm assuming that the signing takes place from the workflow attachments and is done via a user step in the workflow.

The workflow step user interface is unaware of the signing initiation or completion. So without some "hacking" (i.e. changing the OpenText workflow pages/code/Smart View etc and resulting potentially in an unsupported setup) you won't be able to detect these events.

And if you're on a OpenText hosted cloud environment, that's unlikely to be permitted.

The immediate thought I have is whether you have access to the XML Workflow Extensions and Interchange modules that OpenText have, and whether the XML result from the signing platform could be directed somehow to these based on the workflow. (i.e. as I recall, the XML Interchange allows you to provide a URL that an external application can send a response to).

Think of the XML step in the workflow provide a webhook address. If the signing application has a means to call a webhook, then this might work.

Nitesh harjai

Thanks David let me look into this using XML sorkflow extensions as this solution is on cloud i am not sure it will support external signing or not.

appuq

@David Henshaw can he receive the XML response in a Folder monitored by a WR trigger, or if elink was active the response could be sent to a folder(elink I am not sure if it is supported for inbound mail now)

Step 4 :- Signing application will send the XML response and now based on that response I need to push the workflow to next step ?

I understood it like DocuSign does , it will send the signed document to an email.

Interchange is ist still in play? I am seeing XML WF Extensions even in cloud but not the Intercahnge

Nitesh harjai

Hi @appuq ,

Just to be clear again.
Step 4 :- Signing application will send the XML response and now based on that response I need to fire the Get request to sign application to download the final document into my content server application.

As document will go for multiple signing parties and at last sign application can send XML file using webhook.

So main challenge is if sign application is sending XML content to xECM application how I will process/store the response as I am on xECM cloud 24.3 version.

Thanks
Nitesh

appuq

Who monitors the XML Response received? is that a Program you wrote? BTW, @David Henshaw, he knows this much better than I do as he has a product that does signing and he is a seasoned Oscripter so perhaps wait for him to comment. I have used a competing product called Answer Modules and their integration is very nicely conceived. It offers complete workability within the DocuSign platform.

Nitesh harjai

We are still in phase to get the XML file from sign application to content server direct I am not finding the mechanism to get the file in xECM as we are on cloud we don't have directory access to store the file ,

Additionally, file is not being directly getting into xECM folder structure using webhooks.

Note :- XML file will be sent by signing application to google drive/sharepoint I have tested that.

appuq

In very old times OT had a product called Elink(this is an old article I wrote https://www.tek-tips.com/fd orums/862/faqs/7885 things ought to have changed now). What I was thinking is you could designate a Folder and give it an email alias so something like (myxmlfiles@mycompany.xyz) so when your Sp/Google Drive gets it you could possibly see if they could SMTP the file( a relay). assume everything goes well now you have the file in your folder albeit the alias. So depending on your design the XML email you received now has something that you can rely on based on a trigger condition. Since these are mail protocols OT shouldn't be concerned with K8S file systems and so on although recently when I looked I saw a flag that says store it in the database in that product. Perhaps OT may have realized that XML WF extensions is better now for DB storage.

You could also simplify this and not worry about elink. If you have Google Drive/SharePoint you could write a listener there to call CS REST API to do your WF stuff I think.

Perhaps I am oversimplifying so you may ultimately know what the constraints you have.

Nitesh harjai

Thanks @appuq for the help but I am not using google drive/share folder I will try WF extension and see if I can process workflow further based on the XML response.

David Henshaw

In lay terms, the signing application returning the XML needs to have an endpoint that it can return it to. Depending on your environment and any parameters/constraints you need to work within, that will determine "what next".

Unless you have control of the signing service itself (in which case you could use the OT APIs to file the document), then you'll need something that receives the XML and does any required processing.

As the customer is on OT Cloud - this may be an influencing factor in how this is done, as you may or may not be able to deploy custom logic/code into the environment.

Conceptually, as I've mentioned, you might be able to do this with XML Workflow Interchange (availability in the OT environment permitting) - as I recall it as a step that can have a web address and receive the incoming XML, then you could possibly use WebReports or other workflow steps to process and determine actions.

Alternately, you'll need an intermediary - i.e. some service sitting somewhere that receives the XML and then makes API calls to the OpenText environment to do what you need.

To be frank - the question here at this stage isn't "what should I use", but rather "what does my architecture need to look like"

Nitesh harjai

Let me try that workflow XML WORKFLOW extension.

Thank you very much David for your valuable inputs and time

Nitesh harjai

I have explored all available approaches, but unfortunately, I have not found a reliable way to capture the webhook events in xECM Cloud. Since no event is being captured, I am unable to proceed with advancing the workflow.

While the XML workflow extension works when it receives a specific file, allowing it to act accordingly, we are currently unable to receive any files in xECM through webhooks from the third-party signing application.