Who's On?

	Membership:
	Latest: Saef
	Past 24 Hours: 0
	Prev. 24 Hours: 0
	Overall: 5226

	People Online:
	Visitors: 483
	Members: 0
	Total: 483

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1372
Roger French	1315
mark.cook	1244

Multi-threading batch AR cash applications

5 Replies

3 Subscribed to this topic

43 Subscribed to this forum

Sort:

Author

Messages

Todd Mitchell

Veteran Member

Posts: 87

2/16/2016 3:28 PM

I am inquiring to see what solutions anyone has come up with for multi-threading batch AR Cash applications. We have been using AR575 (ARIPMT) for years and this has served us well. However, the larger we grow we are finding that the limitation to AR575 only allowing 1 user or "process" at a time was becoming troublesome. We then went to using AR580 as well. In order for this to work I had to customize AR575 and AR580 because they were not addressing the Batch Nbr "locking" correctly. This also has served us well for the past couple years.

AR575 and AR580 are both limited to 1 "grouping" at a time. Meaning that only 1 user can process transactions at a time. This is becoming more and more problematic as the users are spread out over multiple locations. They can no longer stand up and "yell" "I am running a AR580, so no one else can until I am done".

Has anyone found a creative solution around this?

John Henley

Posts: 3353

2/16/2016 7:24 PM

May work for your particular needs but here are two possible (and quick) solutions off top of my (balding) head:
- you can try changing AR575 in pgmdef to not run concurrently; that will force subsequent submissions to wait in queue
- set up a separate queue with job limit of 1, and assign it to the AR system code

Todd Mitchell

Veteran Member

Posts: 87

2/16/2016 8:17 PM

Not sure how changing that will help since AR575 uses the ARIPMT and ARIPMT has to be loaded with data. AR575 will then process everything in ARIPMT regardless. We are wanting multiple users to be able to "load" data into the interface table(s) and then having just the transactions they loaded processed into Lawson.

John Henley

Posts: 3353

2/16/2016 8:26 PM

sorry, i guess i misunderstood your original post.
How is the data getting into ARIPMT?

Todd Mitchell

Veteran Member

Posts: 87

2/16/2016 8:46 PM

Our current processing:

AR575 --> we have a custom written cobol program (GS575) that reads a flat file and loads the data into ARIPMT. The first thing this code does is checks to see if any data exists in ARIPMT, if so, the job fails with Invalid Parameters. Once GS575 is completed, the user can run an AR575.

AR580 --> I wrote some perl scripts to read flat files and load the data into ARIPAYMENT and ARIREMIT (no check to see if data already exists). Some scripts auto submit an AR580 after data is loaded, others require a user to submit an AR580.

This conversation does lead me to think that I may be able to check for data, if data exists, sleep for X number of seconds and then check again. Another option i was thinking about was to create an IPA flow that processed the data using standard Lawson screens, thereby removing the interface tables completely. (Was trying to suppress the options I came up with so as not to impede everyone's creative thoughts)

John Henley

Posts: 3353

2/16/2016 9:01 PM

The approach I was suggesting (which I've used with other clients) uses PFI or IPA to receive the data (via PFI's BCI ScanFileClient or IPA channels to detect new file drops), writes to CSV files for ARIPMT, loads via importdb, runs AR575 in a single-threaded queue, etc. The flow can be made to only operate on one file at a time and quietly exit or wait if ARIPMT already has data in it or there are no files left to process. The AR575 job is a multi-step job with the last step being to call the flow again to get the next file. As long as the IPA flow is the only entry point for the transactions, it does the trick. Poor man's orchestration, but it works.