Webrun node submitted job three times - should only have been once??

I have a fairly simple flow. A user places a file in a specific location - a File/Channel in Rich Client detects the file, passes it to the LSF server and then a Lawson job is kicked off (via webrun node) to process the file. It's a CSV file with vendor numbers - the batch program they are being passed to is doing an invoked of AP10 to inactivate the vendors.

I ran it with 10 records, 100 records and 1000 records and it worked perfectly. I then decided to drop 50,000 records in the. The job was submitted via the webrun node - after 15 minutes (exactly - right to the second) the job was submitted again and 15 minutes later it was submitted a 3rd time. The 2nd and 3rd job went into waiting because the program being executed is non-concurrent. As soon as the first job completed successfully - I realized a second job was running and that's when I saw the multiple jobs so I killed them.

1^st job started at 13:28:11

2^nd job started at 13:43:11

3^rd job started at 13:58:11

I have NO idea why this is happening. Neither does Infor support so far. The flow in total ran about 44 minutes from start to finish (including the job). I think if it had run longer - I'll be a 4th iteration of the job would have been submitted (exactly 15 minutes after the 3rd iteration).

Anyone ever seen this? ANY ideas at all on what could be causing it???

Thanks in advance. We are V10 On premise.

Find more posts tagged with

Process Automation (IPA) - General Discussions

Accepted answers

All comments

piya

Are all of the records in the same file that is generated? Could it be that the File Channel doesn't have time to send it to the IPA process and move the file before the file channel triggers again? Based on your time stamps it seems that the process is exactly 900 seconds apart. What is your timing delay for the file channel?

Or could it be that the process generating the file is locking the file so it cannot be removed until the third time it "detects" the file?

laura-patenaude

All the records are in the same file. The file Channel checks every 60 minutes so that wouldn't be it - but that is a good thought. But you are right - the fact that it is EXACTLY 15 minutes apart just seems WAY too coincidental. At the end of the job - I display the the record counts and the first job definitely processed all the records.

russel-cornelson

Good afternoon Lynne,

Just a hunch here, does your "JobSubmit" include "&wait=true"?
If you are submitting your job with wait=true; and the job takes longer than the timeout on the Web Run configuration; it will execute "retry" logic. Thus you get the job submitted multiple times. I have a knowledge base article showing how to accomplish this with process automation so that you don't hang the thread.

If I am incorrect; you should include your flow on an incident with IXS and I would gladly assist you.

unknown

Hey Lynne,

Thanks to Russel's comment this sounds familiar. I did not have an issue with a WebRun Node submitting 3 times in the past. My issue was I needed to know the job finished running in Lawson before moving to the next node in the flow. I think it was Russel that helped me with this in the past. Here is what you will need to do:

1. Add the following variables to the Start Node (these will be needed later):

jobNumber

jobStatus

2. Add an assign node after the WebRun Node. Put the following JavaScript in:

var xmlString = INSERTNAMEOFWEBRUNNODEHERE_result.replace(/<?xml.*?>/, '');
var myXML= new XML(xmlString);

jobNumber = myXML.QUEUEDJOB.@jobNumber;

jobNumber = "0000000000" + jobNumber;
jobNumber = jobNumber.substring(jobNumber.length - 10);

3. Add a 2nd line in the Assign Node and assign the Variable jobNumber to jobNumber

4. Run a 2nd WebRun Node with the following populated in the Web Program: /lawson-ios/action/ListQueuedJobs?filter=jobNumber%20EQ%20<!jobNumber>

The Method in the WebRun Node should be GET

5. Insert a 2nd Assign Node. Put the following JavaScript in:

var xmlString =INSERTNAMEOF2NDWEBRUNNODEHERE_result.replace(/<?xml.*?>/, '');
var myXML= new XML(xmlString);

jobStatus = myXML.LIST.QUEUEDJOB.@jobStatus

6. Add a 2nd line to the Assign node and assign the Variable jobStatus to jobStatus

7. Add a Branch Node with these conditions:

Still Running: jobStatus == "running" || jobStatus == "waiting" || jobStatus == "waitingStep" || jobStatus == "waitingRecovery"

Abnormal Completion: jobStatus == "needsRecovery" || jobStatus == "cancelled"

Submission Failure: jobStatus == "invalidParameters" || jobStatus == "queueInactive"

Completed Successfully: true

Still Running should route to a Waite Node that points back to the 1st assign node after the initial WebRun node that assigned the job. It will go through the process again to check the status of the job.

Abnormal Completion and Submission Failure should go to Landmark Nodes to query the error and route to a User Action.

Completed Successfully will route to the next step in the flow.

If you give me your e-mail address I would be happy to send you a copy of a flow where we utilize this logic. Thanks!

Gelangens_Anlage_Entwurf.pdf

unknown

Hi, I think Russell is onto something here. As an experiment, I set up a very simple flow with only a webrun, start, and end in it, and set the webrun node to submit a long running batch job (HR155 for all groups) with wait=true. I changed the Time Out value in the webrun configuration in our test environment from 12 to 1. Then I submitted my test flow, expecting *something* to happen after exactly one minute, and it did. A second instance of the job was not submitted, but I got the following error which kind of sounds like it did try to submit something but couldn't, probably because my test flow was too basic:

WebRun8090_errorCode = 1
WebRun8090_informationCode = 0
WebRun8090_returnMessage = WebRun WebRun8090: Success string Job Has Been Submitted not found
WebRun8090_outputData =
Activity failed: WebRun8090
Activity WebRun8090: Error evaluating expression: ProcessName
Activity WebRun8090: Error evaluating expression: WorkUnit
Activity WebRun8090: Error evaluating expression: ProcessName
Activity WebRun8090: Error evaluating expression: WorkUnit
com.lawson.rdtech.repository.DataArea$UnknownDataAreaException: Data area gen unknown
at com.lawson.rdtech.repository.DataArea$UnknownDataArea.cachedDataArea(DataArea.java:470)
at com.lawson.rdtech.repository.DataArea.load(DataArea.java:435)
at com.lawson.rdtech.repository.DataArea.getEnvDataAreaName(DataArea.java:220)
at com.lawson.bpm.db.model.abstracts.ServerDatabaseModelImpl.<init>(ServerDatabaseModelImpl.java:24)
at com.lawson.bpm.db.model.DatabaseModelFactory.getServerDatabaseModel(DatabaseModelFactory.java:46)
at com.lawson.bpm.coreutils.ConfigurationParameter.getParameter(ConfigurationParameter.java:297)
at com.lawson.bpm.coreutils.SystemConfiguration.isEnvironmentSecured(SystemConfiguration.java:1228)
at com.lawson.bpm.processflow.utility.PFlowUtils.sendMail(PFlowUtils.java:148)
at com.lawson.bpm.processflow.utility.PFlowUtils.sendMail(PFlowUtils.java:90)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgActivity.handleActivityError(FgActivity.java:807)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgaCgiRun.startActivity(FgaCgiRun.java:780)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgActivity.execute(FgActivity.java:1036)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgProcess.run(FgProcess.java:2918)
at com.lawson.bpm.processflow.workFlow.flowGraph.FgProcess.run(FgProcess.java:2707)
at com.lawson.bpm.designer.runtime.LocalFlowRunner.run(Unknown Source)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

Terminating the process ...

unknown

Correction! It DID submit a second instance of the job after one minute! Apparently it just took a little time for our test portal's waiting queue to refresh. So definitely check your webrun configuration set up as Russell suggests, and try pumping up your time out value to see if that helps!

Gelangens_Anlage_Entwurf.pdf

russel-cornelson

You guys are all awesome, I love this Community.

laura-patenaude

Thank you everyone!!!! Yes - I do have "wait" set to "true. I just got a response from Infor support that also told me to try changing the Time Out value in the configuration for the WebRun node. Currently, we have NO value in there (as I said, I'm still learning!) - so I asked Infor what the default would be and they had no idea. But - everything you are all saying makes PERFECT sense (especially since the jobs are 15 minutes apart to the second). I'm going to bump up the TimeOut to be an hour (I THINK that value is in seconds?) and Infor support also suggested changing the Retry value to just 1.

Thanks again - I'll post if everything works but it sounds like you all have already figured it out - Laura

laura-patenaude

Quick question ... In the document that Infor sent me yesterday - they indicated that the Time Out is the number of SECONDS before retrying again and this field only allows for 2 digits which would mean a maximum of 99 seconds - so that won't help me because my job runs about 40 minutes ... It looks like you are saying that setting is actually MINUTES, correct? I am going to try setting this to 60. Thanks!

laura-patenaude

Well - I REALLY thought that was the answer - but I'm still in the same boat. I changed the Time Out to 60 (assuming 60 minutes). I triggered my flow - the first job was triggered and it ran for 15 minutes and ONE SECOND - the second job was submitted at the 15 minute mark. So because the job ran for one second over 15 minutes - a second job was submitted. It didn't submit three times because this job ran faster that the original job did - so I only ended up with 2 jobs being submitted.

Infor has suggested that I change the Time Out to "-1" and the Retry Count to 0. So that is the next thing I am going to try... More to come.

laura-patenaude

Infor's suggestion was a failure. The job didn't even submit once. The webrun node immediately failed.

unknown

What if you set the time out back to 60 and leave the retry at zero?

unknown

This set up is working for us. The key is the QUEUEDJOB loop that grabs the status of the job. Then, the branch node checks the status. If <33 it will loop through and check the status again. Sleep is javascript that waits 60 seconds before checking the status again. For larger jobs, this
"sleep" may be longer. I hope this helps!

laura-patenaude

Thanks Tammy. I may have to try that route - but it seems crazy if they have all these settings for a web run configuration in Rich Client - why should we have to build logic to check if a job is still running? I have the WAIT=TRUE for my job so that the flow will not continue until the job completes successfully so if the Wait option exists - why do we have to keep checking to see if the job is running? I'm just pushing back on Infor first because it sounds like there is a bug somewhere on their side ...

unknown

Agree 100%!!

unknown

it sure would be interesting to actually understand how all the configurable values for webrun work together!

BTW, I noticed in your original post that you are v10 on prem. We are as well. We use a variation of the checking logic others are describing here in our flows. But, since we can, we use sql over the QUEUEDJOB table in GEN (using the job number from the XML output of the job) instead of branching. It's faster.

The below sql is in a sql node after the XML node that follows each webrun. It will check the status of the job every .1 seconds. Note: the query also contains a table we created to hold descriptive text for each status code, for notification emails. It's optional.

DECLARE @status as integer
DECLARE @timer as decimal(8,0)
SET @status = 0
SET @timer = 1

WHILE @status = 0
BEGIN
WAITFOR DELAY '00:00:00.100'
SET @status = (SELECT STATUS FROM <!GENDB>.dbo.QUEUEDJOB WHERE JOBNUMBER = '<!jobNumber>')
--PRINT @status
IF @timer = 6000
BREAK
ELSE
SET @timer = @timer + 1
--PRINT @timer
END

SELECT B.CODE, B.DESCRIPTION
FROM <!GENDB>.dbo.QUEUEDJOB A, <!DataBaseName>.dbo.tblLawJobStatusCodes B
WHERE A.JOBNUMBER = '<!jobNumber>'
AND A.STATUS = B.CODE

jocurrin

Hi there - just curious about whether you have the success string defined in your webrun and if yes, what that is set to?

laura-patenaude

Here is a screenshot showing what it is set to - I use this same success string in all my flows where I am submitting a job and I've never had an issue until now.

0909090854053232.pdf

jocurrin

If you hit the Ctrl-space bar, does something like your jobname with the word completed show up? We are on V10, and our configuration is set to <STATUS>63</STATUS>, but this flow has been in place for a long time so may not be using the latest features.

rm_benefit_administration_aca_training.pptx

moellerg

@jocurrin Lawson has been using the same job codes for S3 since before I started this job 16 years ago... here's the ones that I've been able to figure out:

# 0 - Running
# 30 - Waiting
# 31 - Waiting Step
# 32 - Waiting On Time
# 33 - Waiting Recovery
# 34 - Needs Recovery
# 35 - Invalid Parameters
# 36 - Queue Inactive
# 37 - On Hold
# 60 - Recurring Skipped
# 61 - Recovery Deleted
# 62 - Cancelled
# 63 - Normal Completion

jocurrin

Thanks Greg - I did see that the available variables included "<jobname>_success". I'm just wondering if that is the same as the 63 status. Would make it easier on new developers

Wichtige Hinweise zur PROFILE Donglelizenzierung.pdf

jocurrin

in case the smiley emoji I inserted is covering up the variable I typed in, the variable is "<jobname>_success"

laura-patenaude

Thanks Greg. I've actually been a Lawson developer for almost 25 years ... I can't believe it's been that long. I started back on V6. But my current employer was my first exposure to IPA - we didn't use it at my previous 2 employers - so I'm learning as I go. I just uploaded more details to Infor support - so I'm waiting to see what they come back with.

russel-cornelson

Can you send me an email: russel.cornelson@infor.com and let me know the incident number you have?

User Group Webinar - IDF Part 2-20191112 1603-1.mp4

laura-patenaude

Just sent it to you. However, Lawson support replied late yesterday that it is the Wait=True that is causing the problem. They told me if the job runs longer than 15 minutes - I cannot use this option in the webrun node. I explained to them that their classes teach you to use that option as do some of the Lawson partners that we have used. I have about 20 flows that are using this option and there has never been a problem.

This is the response from Lawson when I asked why "wait=true" wasn't working since the purpose of it was to hold up the flow until the job completes so if there IS a REAL issue - the rest of the flow won't run:

"That is supposed to be the function of wait=True, Laura, however for this scenario where the job completes longer, this is not recommended (as stated in the KB as well) and this because it can cause things to time out, takes up a work unit thread, and ultimately causes more issues than it seeks to resolve."

Very frustrating - although they did send me a sample .lpd file on how to do the looping and keep checking for the job to complete - but it sure seems crazy we have to do all that extra work when this option on the webrun node SHOULD work since that was it's PURPOSE.

robert-canham

If you're on Landmark v11, you can make your job processing reusable with a subprocess. I set it up so I set the jobname and jobuser variables and get a jobresult out of it and don't have to rewrite the processing in every flow I create.

laura-patenaude

Hi - I'm sorry I should have indicated we are on V10 of Landmark. I'm going to have to use the example that Infor gave me to keep looping to check the job (I think others mentioned they do this as well) and retrofit that into my flow. Apparently if your flow runs longer than 15 minutes - using the wait=true is useless.

Gelangens_Anlage_Entwurf.pdf

Copyright © 2025 Infor. All rights reserved.