I hate surprises. I hate surprises to the point that I actually don’t care if I know what happens in a movie before I see it. Consequently, I spend a lot of time trying to figure out what is going to happen next, just so I’m not surprised. This got me thinking about predicting the future with Process Automation (yes, I realize this is an odd thing to think about, but you have to have a hobby, right?). It is fairly easy to figure out what happened in the past in a flow. This could be done either through a variable you have set or viewing the output variables from the node, but is it so much harder to figure what is going to happen next? As it turns out, not really.
I’m not sure that I have a business case for this, it’s just an interesting exercise which is why you got the preamble about me and surprises. Back story aside, Process Automation (and Process Flow – although slightly more complicated) can be self aware. By being self aware, and given that a flow is a static set of instructions, you CAN predict the future – as in you can figure out what will happen next within a flow. Before I lose everyone, I guess I should start getting to the good stuff.
It all starts with the fact that a flow is an XML document. With Process Automation you can read the XML that comprises the flow and search for the information that you need using E4X syntax. All of the information about the flow is in the XML, so you can effectively read ahead to what the flow will do next and thus predict the future.
- Run a landmark query to retrieve the XML of the flow. If you’re using Process Flow integrator, you would need to retrieve the XML from the file system.
- Parse the string information into an XML document
- Email node – it just exists so we can read it.
_dataArea="prod" & _module="pfi" & _objectName="PfiFlowDefinition" & _actionName="Find" & _actionOperator="NONE" & _actionType="SingleRecordQuery" & _pageSize="30" & PfiFlowDefinition="ReadFutureNode" & CurrentFlowXml
Note that this assumes that you know the name of the flow and that it has been published to the server
The XML document has the following basic structure:
<process> <processUserNode></processUserNode> <activities> <activity> <prop><anyData><anyData></prop> ... <prop><anyData><anyData></prop> <OnActivityError> </activity> </activities> <edges> <edge /> ... <edge /> </edges> </process>
- processUserNode – contains information set at the process level
- activities – contains all of the activity nodes
- activity – information about the node itself (type, location, etc)
- prop – the settings in the node. There may be many prop nodes
- OnActivityError – contains information on what to do on error
- edges – container node
- edge – indicates the “next” node
Retrieving the To value
I recommend this page as a reference for using E4X
//Find 'this' node in the edge list var xmlThisNode = XMLParseFlow_output.edges.edge.(@from=='Assign8190'); //get the ID of the next node (email) var strNextNodeID = xmlThisNode.@to; //Get the activity node for the email var xmlNextNode = XMLParseFlow_output.activities.activity.(@id==strNextNodeID); //Pull the To property var xmlEmailToNode = xmlNextNode.prop.(@name=='to'); //Get the value of To strEmailTo = xmlEmailToNode.anyData;
I suppose you could use this technique to retrieve the initial value of the Start node variables to see if they have changed during the flow. There might be other uses as well. I’m not sure if this is really something you would ever actually do in a production environment, but I feel better knowing I can predict the future.