Interface Lawson with 3rd party Report System

Hi aathum, I don't think I completely understand your requirements, but we do something similar to have job output files emailed when the job completes.   To do this, we have a script with parameters for the username, jobname, filename, and email address.  This script first calls "wtsubmit" to launch the batch job and wait for it to complete.  Once it completes, then the script pulls the required file from $LAWDIR/print/username/jobname/1 folder and emails it. Note that in our case these jobs are launched by an external scheduler, which ensures that the parameters are correct.  If you are wanting something that is run on-demand by a user, then it gets more complicated.  In this case, a multi-step job where the 2nd step calls a script on your server with the appropriate parameters could do the trick.  Unfortunately, this is something that would probably have to be configured by an admin rather than by the user.  It would probably also take some fiddling to get it to work as you expect. Good luck.

Woozy: Are you sending the "PRT" file or a converted "PDF" file?   I have only seen ways to automate the sending of the PRT file because it looks like the system does not create the PDF until it is called by the portal system... aathum: I am not sure I totally understand what you are trying to accomplish.   It sounds like you are trying to take information from a 3rd-party tool and use it to update a Lawson Job, run the job and then email the output.   If that is the case I think it is important to know what type of job because an update job is different from a report (list) job.   If it is just a report job I would probably look at doing something outside of the lawson delivered jobs...   However, if you are running some type of update job it probably makes sense to use a lawson delivered job.    Do you have Process Flow integrator?   (You could trigger a flow that looks at the data in another system, modifies the Lawson job accordingly, submits it, and when it completes have it send the output of the job via email or just the URL link if this is for someone internal.)  

Shane: We do this with pdf and csv files, as well as the other output methods.  We use the "bldxffiles" command-line utility to generate these files after the job completes, though there is also a way to configure jobs, systemcodes, or prodlines, to always generate these files (we don't do this, but I know there is a knowledge base article about this). The "bldxffiles" utility is actually what is triggered (or a version of what runs) when you click the PDF or CSV output options from print manager in Portal. We do own PFI, and that is certainly an option, particularly if there is the requirement to modify jobs with external data.

Thanks Guys! I appreciate all the responses. Yes I would see how I can get the job name, user and file name from submitting the job first, then going after the output generated after the job completed and using the parms from the first step and sending that file along with the right data to the third party system.   What I was hoping was that it would be possible to take a print file directly from the PRTMGR and grab those parms at the time someone selects and directs the file to a reserved printer name. I know the GEN file that contains all the details that are listed in the PRTMGR, but I can't "tell" which one is selected for printing when it is. Portal generates a web.exe call at the time someone selects a file for printing, but we do not want to modify Portal . So in addition to the great suggestions of the submit run and print through an external source like a job scheduler or script, does anyone know another way to "trap" output from the print command in PRTMGR?

Woozy, how do you "grab" the parms that go to the bldxffiles program? How do you know which file you want to send to the bldxffiles?

Well, we do it two ways, but I don't think either of them will help with what you are doing.  In our case, these jobs are run by our external scheduling tool (ControlM) which runs a specific Lawson batch job, then passes the same parameters (user/job/step) to a script which generates the output files, then passes more parameters to another script which emails the files.  There is no "user intervention" in these jobs in our case as it is all done autonimously via the scheduler. The second way we do it (also via ControlM) is to create one script that does all the steps, so the parameters are just script params that are re-used.  Then ControlM calls the script which does the grunt work. To solve your particular problem, what about creating a multi-step job for the user to run, where the 1st step is the batch program, and the 2nd step (or 3rd or 4th or whatever it takes) calls a script which generates the files and then calls the lpr command?  Each job would have to be defined up-front with the appropriate parameters for each step, but it should allow you to design the calls to the command line to do what you need to do. To do this, you would need to create your script and save it someplace where Lawson can get to it, then create a token (using tokendef) that calls your script with the required parameters and make this token another step in the job.  Since all the info is within the job, you should be able to define it, though it will probably take some trial-and-error to make it happen.  Note that if you are using LS security (I'm not sure about LAUA) then the users would need to be granted access to the new token. You may not want to go down that path, but it might be something to consider.

We do just exactly what Woozy says for most of our scheduled jobs. Right out of recdef. Creating shell scripts, then tokens and inserting them into our job flows. I believe we even have a couple that call bldxffiles --- If you're on Unix, I can provide a sample.

Thanks Greg! I would appreciate that. arthur.thum@visionarypilotage.com I am doing Windows right now, but am well versed in Unix too so that would be a great help!. Thanks everyone!

Do you need a sample of tokendef, and the rest of the Lawson-end set up? Or just the script that calls bldxffiles?

Here's a working script that was requested by one of our users to run with his RW100 job.

Hi, Could you please guide me as to how to obtain the report through email i have access to LID in Unix environment . Thanks, Suhas