Who is my child?

Has anyone come up with an elegant way to raise a flag to start a child process and retrieve the child process folder id that was created? As it stands I have a method I use that queries the database looking for parent folder Id's and returns an object of all children. It would be nice if the raise flag event either had a callback method or a return value of the newly created folder. Any suggestions?

Find more posts tagged with

BPM

Comments

Brian Mellert

I tend to use the "check eFolder for eParent" approach myself, but I can see the situation you imply. Flags do not necessarily run immediately (but often do), so a direct return value is not an option. Two ideas off the top of my head:

You could create a flag in your parent process which gets called from the child process, which will return as a parameter the child's folder ID.

Another potential option, if you are just trying to store the child's Folder ID in the parent parent, you could add the parent's BO to the child process and assign the value directly in the BO as the folder is created.

achopra

Another approach would be to use the ECL for .NET or WS to take the action, rather than using flags. Those would be synchronous calls which would return the folderID back to the calling application (or process). This would require a bit of C# coding up front, but in the long run, might be better for what you are trying to do than flag raising.

Aaron Van

BMellert,

Yea I have done the fake call-back approach by having the child call the parent again to signify it has kicked off. It worked well in the situation we used it for. In this instance I am trying to keep all code out of Metastorm and in our MVC app.

Ari,

It's funny, I opened another instance of the Designer to add an action alongside the current flag to see if the ECL method would return the new folderId and saw your response in the News Feed. Our entire application is using the ECL to move the workflow along since we opted for html/razor for our views rather than the form designer. So the coding doesn't bother me, I just don't like hard coding action names to call, but I guess that's no different then hard coding flag names in some of our service calls.

Thanks for the responses, I'll let everyone know how it turns out.

Paul Denton

Ari mentioned a core point there. Flags are inherently asychronous, they are fire and forget and you have to accept that if you chose to use them.

If you really want to make sure the event occured and get data back from the event they Ari's suggestion to use the client API (the ECL) to perform the action synchronously is the way to go (and is commonly used by some customers and the services team)....

Of course one challenge is that method does not inherently create a parent/child relationship...

Aaron Van

pdenton,

That's a great point about the workflow not being inherently a child of the calling process.

I'll have to write to the process variables in the action in the same manner I am for the original flag.

I already have a wrapper for the start action ECL method which returns the ActionResponse which includes the folderId.

Good catch pdenton, that could have bit me if I didn't scope it out.

Jerome_Pearce

pdenton wrote:
...

Of course one challenge is that method does not inherently create a parent/child relationship...

That is a completey undocumented feature, BTW. I often wonder if it will be removed at any point, and then we'll be told that it never appeared in the documentation so it is not supported. It would by no means be the first time this has happened.