AGS Fail occasionally

Could you include your AGS?   Might be helpful to see if you have any Keys missing....

I'd start by looking at the WF log.  We just implemented PF for PO approvals and I've been able to solve a few issues looking at these.  Start by determining the ID number of the AGS call and then search for it in the log.  I should mention we are an iSeries shop. 

What I've seen in the past with this is the call fails with a security error - which makes no sense since "lawson" usually performs the AGS call. I've seen this with iSeries and Windows clients and it usually required an update to the most recent version of ProcessFlow to resolve.

Thanks for the replies guys. We are on Windows, and I believe this started when we went to LDAP. Not sure if that has anything to do with it though. This is what I've been able to find so far:


Executing activity : Type=AGS, ActivityName=Transaction130, ActivityId=AGS159, Workunit=148046 Date:02/22/2010 Time:13:01:09
Log in Process : reqapproval2_V08 Workunit : 148046, ActivityType=AGS, ActivityName=Transaction130, ActivityId=AGS159 Date:02/22/2010 Time:13:01:09
Executing Ags Activity Transaction130.....
Log in Process : reqapproval2_V08 Workunit : 148046, ActivityType=AGS, ActivityName=Transaction130, ActivityId=AGS159 Date:02/22/2010 Time:13:01:09
Transaction Call String _PDL=PROD&_TKN=RQ13.1&_EVT=CHG&_RTN=DATA&_LFN=ALL&_TDS=IGNORE&FC=Approve&RQH-COMPANY=0001&RQH-REQ-NUMBER=256624&_DELIM=%09&_OUT=TEXT&_EOT=TRUE
Error while Executing activity : Type=AGS, ActivityName=Transaction130, ActivityId=AGS159, WorkUnit=148046 Date:02/22/2010 Time:13:01:09
ErrorLog in Process : reqapproval2_V08 Workunit : 148046, ActivityType=AGS, ActivityName=Transaction130, ActivityId=AGS159 Date:02/22/2010 Time:13:01:09
Error while executing Ags Activity .....java.lang.Exception: Error connecting to http://"server":80/servlet/Router/Transaction/Erp?_PDL=PROD&_TKN=RQ13.1&_EVT=CHG&_RTN=DATA&_LFN=TRUE&_TDS=IGNORE&FC=Approve&RQH-COMPANY=0001&RQH-REQ-NUMBER=256624&_DELIM=%09&_OUT=TEXT&_EOT=TRUE with user "edit" Query string
at com.lawson.bpm.coreutils.CGIInvoker.invoke(Unknown Source)
at com.lawson.bpm.coreutils.CGIInvoker.invoke(Unknown Source)
at com.lawson.bpm.coreutils.CGIInvoker.invoke(Unknown Source)
at com.lawson.bpm.database.transaction.Transaction.doQuery(Unknown Source)
at com.lawson.bpm.database.transaction.Transaction.doQuery(Unknown Source)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgaAgs.startActivity(Unknown Source)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgActivity.execute(Unknown Source)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgProcess.run(Unknown Source)
at com.lawson.bpm.pfengine.ProcessFlowEngine.execute(Unknown Source)
at com.lawson.bpm.pfengine.ProcessFlowEngine.startProcessAt(Unknown Source)
at com.lawson.bpm.eprocessserver.KBConnection.startProcess(Unknown Source)
at com.lawson.bpm.eprocessserver.KBConnection.startProcess(Unknown Source)
at com.lawson.bpm.eprocessserver.KBConnection.execute(Unknown Source)
at com.lawson.bpm.eprocessserver.KBConnection.run(Unknown Source)
at com.lawson.bpm.eprocessserver.util.ThreadPool$PooledThread.run(Unknown Source)

It appears that it may be a security error. Am I correct in thinking this?

Just a note, I did change the servername above to "server" and also changed the user to "edit" .

Well, we opened a case today with support and they are saying it is a communication error.

Hi Kurt -

Security errors usually occur continuously, rather than intermittently and you'll get that nice "security violation" message etc.

The fact that this occurs sporadically leads me to think this is a record-locking timeout error. I've seen this in the past with several clients on DB2, but can also happen on other databases. Look at your concurrency settings on the various tables in question in the query - sometimes the DB is configured for record locking on the table vs. the row. Your DBA can make the changes. You might also want to review your configuration via pfserv config - again looking at the threads.

Thank you for the replies. Still looking into this...

We get the exact same "Unknown source" in the java debug and "error connecting to". For us it happens every time and not sporadically. I agree that it is not a connection issue. It is something else. For us, it only happens when you check "Run on server"...locally works just fine.

Joe

Kurt,
Did the user change when you click the run on server box I am noticing that it is a service account when I do that an not my user account.
I am having a really difficult time diagnosing this.
Joe

Nope, the user has not changed.

If it's working locally and not when choosing "Run on Server" then it sounds like some type of configuration issue, and those two files (pfserv.cfg and bpm.properties) are involved in the configuration of processflow. I had a similar problem recently and it turned out there was an extra carriage return in the pfserf.cfg in one of the lines which were preventing both queries and ags to fail when running 'Run on Server' (worked fine when running locally).

This is the only case where an AGS call fails. I use AGS for reqapproval and invoices. In this particular case where I use AGS to change a saved AR580 and I choose 'Run on server' is when it fails. So, AGS works, just not in this one particular case. And, if fails every time.

Thanks for the tip. I'll look in the two config files and see what I can see.

Does anyone know what these mean in the bpm.properties?

useCgiAgs=false
useCgiDme=false

We solved our problem with this. For us, the problem was two-fold. One, our service account was messed up. Two and most importantly, we noticed a "bad Lawson character". There was a '\' in one of the parms for the AGS call and it was blowing up simply saying "Error connecting to...."

We changed the bad character to the percent-ascii-hex value. In our case, we had to use '%5C' instead of the back-slash.

Thanks...Joe

Hi Kurt,
Just a thought! I remember you telling me that this occurs intermittently. If Lawson has still not been able to get to the root of this issue; what I would do is trap the AGS Return Error Code after the call, and branch it back to the same node again if its not 0 (Success).
To be safe, introduce an counter since you do not want it to go in an endless loop. Say it fails for 10 times, send an email to PFAdmin and then manually take an action on the Req. This is though not the best solution, but I guess it will surely keep you in business as an interim solution!

Hope this helps!
KK

KK,

Thanks man. Unfortunatley, I can't seem to recreate the issue as it will go through successfully every time I do testing.
I've even checked the SID in AD compared to Lawson as Joe was saying in this thread, and everything checks out. I'm at a lost.
It's more a nuisance than an emergency as we take the action of restarting the requisition in processflow administrator to make it go through. But I would really like to resolve this.

Kurt