Checking Status of Triggered Flow

If you assign a unique description on the WorkUnit that you create (maybe with a date/time stamp) then you could query the WFWORKUNIT (in LOGAN) table for the status of that WorkUnit (and also get your WorkUnit number).

If you created the trigger using an ags call to WFWK, it returns with a success message with the workunit number assigned.

If you want to look it up,  the WFVARIABLE record is probably a better choice, for example invoice approval query for the WFVARIABLE record where VARIABLE-NAME = "API_INVOICE" and VARIABLE-VALUE = the invoice and WORKUNIT.SERVICE = "InvApproval".  The WORKUNIT field returned would then be the workunit number.

 

 

 

Just like what David suggested, you can also tie up your processflow with a service. Example you can create a service called APLoad then tie up your pflow (load AP invoices) to the service, in design studio you can then reference the WFWORKUNIT for the service. There are a lot of fields that you can reference to in WFWORKUNIT such as wf-user-id, task, work-category, work-cat-value etc.

Going after just the WFWORKUNIT does not ensure you are going after the correct one, that is why I suggested using WFVARIABLE, go after something that is unique to the particular flow you are trying to find the status of. The WFVARIABLE table is related to the WFWORKUNIT so you can get to any of the values of WFWORKUNIT by doing a query of WFVARIABLE.

Why not do it all within the processflow itself? Each WU has the user ID of who submitted it. Portal has the user info needed that can be passed to the WU, and YES do attach it to a service. If on ENV 8.0.3, query their RD30 to gather email address (if not available in 8.0.3 Portal, been a while since I've been on 8.0.3), if LSF9, the WU automatically has the user ID of the submitter in the WU record. Use this to query RM to gather name and email or just pass it these values from Portal to the WU service variables that you will define.

In 8.0.3, some flow testing can be done to somewhat determine successful completion of certain nodes, but in LSF9, processflow has many additional features to do this. When you use a node to submit a Lawson Batch Job, it can be configured to wait until the job completes and receive return values from the job. These values can be tested on to determine it's success or failure and email notifications can be sent accordinly.

If the flow is fairly simple, run a few nodes and all the user needs to know is when it completes, just add an email notification to the user as the last node.

Thanks for all your replies. I will see if I understand enough to try them.  I do have an email notification in the Process Flows, it is just that I am used to showing the user immediately that something is successful or not.  I build a message based on whether records already exist in APCINVOICE.  I really do not want them to have to check an email for the status.  I would like to display the message with "alert" or something like "MessageBox.Show" in .net.

The challenge to what you want to accomplish is the there is a "disconnect" between the Portal and ProcessFlow from when you initiate the flow to when it completes.  There is the possibility becuase of traffic on the ProcessFlow server that it will not process immediately.

Depending on what your flow does, a possible alternative would be have the code to update in the actual Design Studio form instead of calling a flow, maybe still call the flow but to do everything that does not require the user be notified.   Calls to Tables, Forms, and Web cgi programs in ProcessFlow can also be done in Design Studio, it is just that you have to write it in Javascript. 

 

Thanks for the help. With a successful AGS call I was able to retrieve the WORKUNIT # with the following code, if MsgNbr is returned with the value of 000:

var sAGSInfo=portalWnd.httpRequest(s);
var sMsgNbr = sAGSInfo.selectSingleNode("//MsgNbr").text;
var sWorkUnit = sAGSInfo.selectSingleNode("//WORKUNIT").text;