ScanFileClient Configuration File Settings

Are you in 80XX or 90XX? Windows or Unix? In 90XX (unix) you simplly submit the ScanFileClient command or better still create a script that has multiple ScanFileClient commands. Make sure that your procedure names and processflows name is exactly the same. In 90XX ScanFileClient is now manage by BPM but you can still create BCI connectors. Here's what is happening:
1. You submit an ScanFileClient which is using a path and extension of .CXV
2. ScanFileClient detects a file with .CXV in the path specified above
3. ScanFileClient (BPM) creates a workunit and call processflow of the same name as the ScanFileClient.

The only configurationis is in the BpmProperties file.

You need to run ScanFileClient with the -ConfigFile parameter for each .cfg file.=

We are using Lawson 9.014 with Unix.
Then we will setup a script to run the ScanFileClient commands but is there any advantage of referring to cfg files using –ConfigFile instead of just inserting the paramer values straight in the command as
ScanFileClient –ScanDir=/lawson/lawson/bpm/flow_scan Extension=.txt ... ?

If we go the route of scripting multiple ScanFileClient queues, can we just add these commands to the startup script so they can run as part of the server reboots?
Is there a way to gracefully shut these queues down?
Is there shutdown part of the pfserv shutdown? Or, do they just die with the shutdown like the EDI MultiServer and SMTPAgent?

Thank you so much for your help, I appreciate it.

Gaston

I have a script that has 30 ScanfileClient commands and this is part of the startup script. I also have a script that list all active ScanFileClient(just to make sure everything works fine). I also have a script to kill all these clients if need be.

Sam,

We were contemplating the idea of having one ScanFileClient command calling a main process flow that will branch to the corresponding sub-process-flows based on the file name instead of having various commands. I wonder if this approach will put too much processing overhead to a single ScanFileClient and if it is worthy dealing with an additional work unit for the sub-process. Did you ever consider this approach of using only one ScanFileClient command instead of 30? If it is not much asking, could you please provide me with a snip code of your scripts so we get an idea how to set this up? When you kill these clients, does it do it gracefully or is not an issue at all?

Thank you,

Gaston

Yes in fact I wrote using Perl script(daemon) but never tested it due to work constrains. 30 ScanFiles never was a problem with memory or performances. At one time I did have more than 50 clients and everything works fine. Here's a snippet of the three ksh files you requested. Nowadays we are converting our interfaces using a product called Axway and ScanFileClient will be a thing in the past except for those pflows that uses data mapping.

StartScanFile.ksh

#PATIENT REFUND TO AP Interface:

ScanFileClient -Procedure PATREFUND -Batch TRUE -ScanDir $CCSDIR/interfaces/IN -Extension .pat1

#LAB REFUND TO AP Interface:

ScanFileClient -Procedure LABREFUND -Batch TRUE -ScanDir $CCSDIR/interfaces/IN -Extension .lab1

#Patient Billing Refund (EPIC to Lawson)

ScanFileClient -Procedure PBREFUND -Batch TRUE -ScanDir $CCSDIR/interfaces/IN -Extension .pb1

#Hospital Billing Refund (Epic to Lawson)

ScanFileClient -Procedure HBREFUND -Batch TRUE -ScanDir $CCSDIR/interfaces/IN -Extension .hb1


ListScanFiles.ksh

ps -ef|grep ScanFileClient|grep -v grep|tr -s ' '|cut -d ' ' -f 3,11,12|xargs -n1 -i echo {} Active


KillScanFiles.ksh


for i in `ps -ef|grep ScanFileClient |grep -v grep|tr -s ' ' |cut -d ' ' -f 3`;do

kill -9 $i

echo " $i killed"

done

Sam,
These snip code examples are very useful. Now we have an idea on how to start/stop the ScanFileClient sessions and I feel more comfortable knowing that a handful of ScanFileClient session will not slow down the system.

Thank you for your help,

Gaston