How to pass the NodeID of the document that initiated the Workflow process?

MarkedOne · 2025-01-05T17:08:15+00:00

There was an error rendering this rich post.

Hi,

I want to pass the node id / DataID of a given document that initiates a workflow to one of the steps in the WF map.

The DataID supposed to be delivered to the Execute step on the WF map. Here's how the map looks :

The goal is to somehow pass the Data ID from the start step to the execute step. Another step in the middle is also acceptable.

This is how the execute step looks :

I have checked all of the available options in the configuration and none of them represents the DataID of the document. There are workflow id,map id, user id etc… nothing helpful.

I have seen that there is "Attribute Value" and it's possible to define one to the workflow :

Is there an option maybe to pass it to this Document ID attribute so it will be accessible to the all steps in the workflow? (like a global variable)

Any ideas on how to achieve this will be appreciated.

Thanks.

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

appuq

No the XML WF extensions is not very straightforward. From memory, we used to do it like this

A user would add a Document DataID e.g 12345 to the WF
WF would have this Document in its Attachment volume perhaps now it is 678910
A Modify Step puts the XML out of the attachment volume and puts it in the server file system.
XML WF parses the dataid now and will get 678910 to a WF attribute or a form
Based on that one finds out the relation as the WF process has a relation and finally comes up with 12345. (Different solutions use different approaches shortcuts, copies, etc)
If you have that as Item Reference you can use the IR step to add a version to the original document.

This was a typical use case that OT published at the time for users, I have used it in the past. However, if you look now with WR step point 3,4,5 can now be done very easily through a WR Extension and does not require server-side setup and configuration :).Perhaps I wasn't making myself clear

The PDF from OT called Advanced Workflow Techniques had an examplemap and its setup.

appuq

I was able to test both the commands using XML WF extensions using Esign code and WFInitiateFromItem.In both cases I was able to show in the XML the Originating Document(the one the user clicked in either Initiate Workflow or Initiate Document Workflow). I put my thoughts along with screencaps in this document.

PS: I have not used the Modify Step to make it into a truly working option, that is for the reader to apply his/her thoughts.

https://knowledge.opentext.com/knowledge/llisapi.dll/Properties/82537452

All comments

appuq

From memory, there is more than one solution that provides a Document Initiate(Template workspaces, Esign and many others). Some solutions make a copy of the Document and put it in the attachments of the WF so if your original dataid was 12345 and the Node inside the attachments area is 678910 then the node 678910 will have in its extendeddata column that 12345. Another solution called ESIGN or TW uses the concept of shortcuts or references so in that case the Nodeid in your attachments will have the originadataid reflected

If you really want to use only XML WF Extensions here's how ten years or upwards we used to do it.

We would put a Modify Step

The Modify step will export the Attachment volume and the Document inside it

Using XML parsing one would then find the dataid in this attachments

and having found it it would be transferred to a WF Attribute or Form Attribute

From that as I said you could deduce where it came from.

Look in old discussions around 2004-2016 for articles written by Eric Sa(a)vedra or Ryan Long there should be a PDF document showing what you want replete with screen caps.

Converting your solution using a WR step might speed up this by 30 minutes or so since I don't know what the Execute thing is doing, but finding what you need without XML parsing can be accomplished by a WR step can be done in less than 30 minutes parsing is so dated hence also this solution involves File systems of the server so cumbersome and less secure.

If you can't find the document called "Advanced Workflow Techniques" you can ask support or indicate here I sure might have it in my old notes.

Chris McC

We have this set up in a 23.1 signing workflow. We use the original id in WebReport steps within the workflow. I think this may only be available in signing workflows, not sure.

For the field to become available, you need to set up an "Item Reference" attribute under the maps attributes.

Once that is set up, under the start step you can reference the source document in the start step of the workflow as below.

We hide the field, so people don't try to populate it manually. It gets populated automatically when the workflow is started which is really useful.

Cheers,
Chris

MarkedOne

https://forums.opentext.com/forums/developer/discussion/comment/970142#Comment_970142

Hi I don't see the option in the start step like you presented it. This is what I have :

Chris McC

https://forums.opentext.com/forums/developer/discussion/comment/970150#Comment_970150

I just had a look, and this option is only available for signing workflows. To make a signing workflow is under Map > General. Not sure when this was implemented, I found it after our workflows broke when upgrading from 16.2.6.

appuq

XML WF extensions are clearly capable of finding which is the Document that is sitting in its workflow, there's no need to convert it into a Signing WF. Signing WFs also has some inherent things like one cannot delete it etc.

XML WF was used in the Livelink workflow long before other better tools like WRs came about.In fact OT published maps and procedures to do it easily. I think that is what I posted in my reply above.

Chris McC

When a workflow is triggered directly from an enterprise document, I found getting the ID of the original document a challenge. Was not interested in the copied one within the attachments folder. The options I found were configuring it to create a shortcut and get the ID from that (Signing workflows stopped creating shortcuts after upgrade so that was ruled out) or this method. Never looked at xml so can't comment on that.

appuq

No the XML WF extensions is not very straightforward. From memory, we used to do it like this

A user would add a Document DataID e.g 12345 to the WF
WF would have this Document in its Attachment volume perhaps now it is 678910
A Modify Step puts the XML out of the attachment volume and puts it in the server file system.
XML WF parses the dataid now and will get 678910 to a WF attribute or a form
Based on that one finds out the relation as the WF process has a relation and finally comes up with 12345. (Different solutions use different approaches shortcuts, copies, etc)
If you have that as Item Reference you can use the IR step to add a version to the original document.

The PDF from OT called Advanced Workflow Techniques had an examplemap and its setup.

appuq

PS: I have not used the Modify Step to make it into a truly working option, that is for the reader to apply his/her thoughts.

https://knowledge.opentext.com/knowledge/llisapi.dll/Properties/82537452

MarkedOne

Thank you very much guys for all the answers! Did manage to get the ID with the XML and modify steps. Still can't find the

Advanced Workflow Techniques

pdf

It's like Area 51.

appuq

As I suggested OT Support can give it to you. I am not sure if I shared if I would be in violation of anything :) to keep the thought on Area 51 😀Also I would have named your WF map something different😀

In reality that is all there is Start-XMLEXport-XML parsing

In retrospect what the PDF used to do painstakingly is what the product does now. To make it work,you make your WF map a Signing one, and then you create a placeholder like @Chris McC pointed above. Then if you use the Esign Request Handler(not the TW spaces RH) then when the WF is started you will have your Source Document mapped to the Item Reference.