Anyone out there know LID tokendef/user id forms/command lines??

I've never setup a user id form and it was suggested to use to run a script file? For instance, right now we use LID to import data in using the importdb command. But, I want to start using IMDBB to import the data instead of giving users access to LID. Since IMDBB can only import one file at a time, I want to use a script to import multiple files at one time, so it was suggested that I put the command into a .txt file which I can save somewhere on the server and them use tokendef to read the file, but I don't know what the command line would be??

Find more posts tagged with

Infor Lawson Technology Group - Discussion

Comments

We now use ActiveBatch to perform these types of scripting. We do many importdb's with this on UNIX environment with no user intervention. The user only receive emails when the data has been imported. Very powerful tool that works across desperate systems. www.advsyscon.com/.../it-automation-without-boundaries.aspx

We are very glad we purchased this product and have rehosted many tasks to this. With Lawson and other programs.

We do have a few instances where ActiveBatch creates the CSV files for input but sends them to the end user. The End User will then upload them via the Portal's IMDB screen. In this case they want to control the timing of the uploads.

Thank you for the information on Active Batch but for now, I need to create this tokendef user ID form.

Are you on a Unix or Windows server?

Windows

I'm on a Unix server and the command I enter in the Tokendef is exactly the same command I'd use if I were to run the script at the command line on my Unix box. If you're on Windows, wouldn't you use a .bat file instead of .txt file for a script?

I was going to put the .bat command in the .txt file that the tokendef would read when a user runs the IMDBB form.

Put your command in your .bat file and call your .bat file from the Command parameter in the Tokendef.

That's exactly what I want to do, but I'm not sure what to put in the command line, just the location of the of the file?
Then the big question is, what do I put in IMDBB for the DB file and File name for it to process the tokendef command? This is where I really don't know what to do?

I'm not positive, but I think just the location and name of the .bat file. Like this: c: est est.bat
I am unfamiliar with IMDBB, so I don't know the answer to that question. When I've used the importdb command, I just put it in my script just like if I were to run it at the command line. Like so:
importdb -r So for me, it looks like this: importdb -r prod1 APCINVOICE APCINVOICE.txt You should be able to repeat that line multiple times in a .bat file to import multiple files at once (one command for each file you need to import).?. Maybe I'm totally misunderstanding what you're trying to do...

OK, from Lawson I was told the following:
IMDBB would be the program in portal that runs the importdb command to load files. With IMDBB you can only load one file at a time.

You could setup a user form ID in tokendef that calls the script you use to load the files. You would set this token up as a multstep job to run the script in portal.

Since I have never setup a tokendef before, of course this was sort of some jiberish to me. So, I looked at the tokendef User ID form and wasn't sure what to put in the command line and then, how do I get IMDBB to read that? That's my problem.

You would use something like:

ksh D:LawsonScriptsimportdb.sh

(ksh to make it operable) Inside the .sh script a location of the CSV.

Our users run a lot of UNIX scripts and the way we do it is to create user tokens which contain the name of the UNIX script to run. The user tokens are then built into submitted jobs or multi-step submitted jobs which are run in batch.

Our problem is that a lot of our scripts contain an initial prompt for a value which prevents us from running them in Portal. We still use LID for running these scripts.

Yes, see that's what I'm trying to change. We run a command in LID right now, it's a importdb_All_CSV_FILES.bat command but, I want to move this into Portal so I don't have to give users access to LID, since it's going away anyway very soon.

LID isnt going away for Admins. You can set the usertoken to run in recdef. On a schedule.

Yes, unfortunately this is not a job we can schedule. Other processes have to take place before we can import this data into Lawson. So, I was hoping to move this away from LID and into Portal.

You can pass input parameters into scripts via Portal. From Jobs and Reports, select Multi Step Job Definition. Add the Job Name and Token. Parameters can be added to the Job Definition. The parameters can then be read from the script that is called by the token. Not user friendly, but it works.

Using Multi-step Jobs are the way we do all of our FTPs etc.

Read in different file, process the JOb (e.g. AP520), then delete the file, as three steps.
This effectively picks up the tpkendef for the transfer as the first step, then deletes the file via another tokndef to delete it.

Assuming you have a set group of files to come in, I like ideas from Dan and Peter - multi step jobs are the simplest answer in my view. You would set up the one job in multi step job definition and then make each import file a step in the job. In this scenario, my multistep job is called importfiles and it has a bunch of steps - step 1 uses IMDBB to import to GLTRANSREL, step 2 uses IMDBB to import to ACTRANSREL, etc. I am more on the accounting side than technical so I find it very nice that I don't have to have help from the IT department to maintain my jobs. I am attaching a screen print of how I think it looks

I have done this before in Lawson 9 ... same issues arose ... I got it to work by doing the following. Memory is a bit rusty but the concepts are:
- Created special script in UNIX to do the file import. In Windows it can be a batch file. Script/batch file can use parameters coming in when it's called
- Set up the script/batch in tokendef, defined it there
- Set up a job referring to the tokendef. The call to the job has to be edited to update for new parameters.
- Set up a menu item to allow the user to click on it when they wanted to run it.
.... and here's the kicker, this got me: Set up security so that the user can run the tokendef! Without security, it ain't happenin'.

- Also making it worse, in both UNIX and Windows, make certain that the user has file rights to execute the script/batch file, and security rights to access the directory it's in. And, security rights to read the incoming file, rights to the directory the file is in, and any directory it's processed into.

So remember, whatever you set up, the user has to have security allowed, or else it won't work.

[Updated on 11/2/2015 8:14 AM]

0712131256598360.doc

Good point re LS9, sorry forgot to mention it.
If you don't set the access for the token (via ENV, and UserForm), then you will not be able to see the Multi-step Job, in order to submit it.

Our users presently run a good deal of interface scripts (Windows bat files) from LID on V9. In order to have the flexibility of running these independently and on demand we will probably not want to incorporate these in to multistep jobs on V10. Although the application access is gone from LID are users still able to invoke scripts that perform importdb, etc on V10? Thanks.

Yes, if you grant appropriate security. They'll need access to importdb, the product line and the tables, and any other Lawson commands used.

We have created custom menus in tokendef to allow users to run only UNIX scripts from LID. Not supported but it still works and we could replace them with scripted menus if we have to.

We created a custom program with multi-tabs for these types of tasks. The user just goes to the tab identified by the task needed, enters the specific data needed to run a certain script, the program dynamically builds the script in a ksh file and executes it. Lid is not needed, just access to the custom program.

Question: When you say you created a custom program with multi-tabs, how did you do that, what did you use to create the custom program?

Just a custom COBOL program or token that can be run by any user that has access to it like HR11 or PA100.

I've seen this type of custom COBOL program before. The technique is, the COBOL code writes out a new script/batch file. As it does this, it incorporates the specific data that the user entered into it. Then, the COBOL program calls the script/batch file and runs it. This ability for a COBOL program to reach out and run scripts/batch files 'from the inside' is very powerful & useful. Also lucrative for consultants, so write carefully and add a lot of comments.

If anyone has a Custom Cobol script that can run a .bat or batch file that you can share that would be great!

If you have Design Studio and ProcessFlow you can do this without needing to create any custom Cobol programs.

> If you have Design Studio and ProcessFlow you can do this
> without needing to create any custom Cobol programs

That is good to know, since COBOL is going away in Lawson 11.

Yes, but if tables and screens are also changing/going away in v11, I'm not sure how valuable Design Studio and ProcessFlow would be either.
I am contemplating implementing ProcessFlow now, but I'm nervous that any work we do now will have to be completely reworked for v11.

Quick Links

Popular Tags