Sending error logs to IT.

Hi Kenn - are you using Classic Processflow (PFA/PFI), or are you using Infor Process Automation (IPA)?  Also, are you using this for S3, M3, LTM, or something else?

If you are using IPA (I hope you are) then you are making it much more difficult than it needs to be.  In that case you can have the node that errored send an email to your IT department including the related error message and anything else you want it to send.  In our case, we use lots of SQL nodes, and I'll actually paste the SQL query into the error email so I can manually run that SQL query and know it is exactly the query the flow tried to run.

Thank you for your reply.  Sadly, we are not using IPA, just Classic (2015 is the target for IPA).  We are using it strictly for S3 and just starting to get a feel for how we can use it and the best ways to develop our flows.

So when checking for errors, would you only ever check for errors on the SQL nodes and not on an assign node (or other node)?  Would there be a chance that a different node would fail and how would you handle that?

It seems that if you branched to an email after every node if there was an error, the flow would get quite messy, but if you did not check for errors until the end of the flow then swend an email, you may have situations that the first query fails and it still runs through the entire flow even after a failure, producing undesireable results.  I was thinking of using the 'Stop Process on SQL error' toggled on to stop the flow at the SQL node and then check for the log.  As you said, I may be making it more difficult than it is (I tend to overthink) but I just see a few ways of handling erros and I'm trying to understand why one way is better than another as well as which way is better.

Thank you for your help!

Ken - yes, sometimes workflows stop for reasons that you cannot trap (or don't want trapped) inside the flow itself. For example, you may have a node that you want to just stop the flow if it fails. You can use a variety of tools - including PF itself - to query the work units for certain status codes and help be proactive in identifying errors in work units.

Ping me personally if you need more info....

Hi Kenn - Since you are using Classic Pflow, then George is probably a better resource.  We use Classic, but only for a very few things.  We've migrated almost everything to IPA.

You make some valid points regarding error handling. Since you will eventually be going to IPA (and for those who are interested), here's a bit more information about the IPA error handling, which is much more robust than Classic Pflow. 

In IPA, for each node that is an IO-type node (S3 Query/Trans, SQL, Landmark Trans, email, UserAction, etc) there is an "error handling" tab that allows you to determine the result of an error on that node from the following options: 1) Stop the Flow, 2) Continue, or 3) use the Custom Error Handler.  For any of the three options you can choose to send notification email (fully customizable) and/or add additional info to the log.  The "send to error handler" option gives a different connector type that routes the flow in the event of an error - think of it as a branch based on having an error code, but without requiring an extra node.  In addition, IPA also allows you to send notifications (outside of the flow) if a workunit fails. if any nodes error in the flow, or when the workunit completes.

Good Luck!

Posted By Kenn on 07/17/2013 05:29 PM
Thank you for your reply.  Sadly, we are not using IPA, just Classic (2015 is the target for IPA).  We are using it strictly for S3 and just starting to get a feel for how we can use it and the best ways to develop our flows.

I would highly recommend that you rethink that; if you're just getting started, I wouldn't invest time/energy, etc. in a product that is being replaced, but would recommend that you implement IPA. It's installed in a separate (Landmark) environment (separate from S3), and will get you one step closer when you eventually upgrade to v10. Just saying...