Post Queues - 2 environments

BillG

Active Member
Hello,
I need to know if it is possible to have different posting job queues for the R09801 in different environments.
Depending what user you logged in as, when posting a journal entry, your batch would go to the specified job queue.
If this is possible, please let me know what I need to do.

Bill
Oneworld ERP 8.0 SP 22
Oracle, Unix, Citrix
 
I know we can change the job queue per version. However, I do not want to create a new version per environment. I would like to create one version which all users will use, but the batch will process in the correct queue based on the user id and environment.
 
You can have the same version with different queue names in different environments - there's nothing wrong with it, it may just be too hard to maintain, but not per user, as you are asking.

Perhaps, with some scripting you might be able to do this the way you want, but there's nothing like that out of the box.

Regards,
Alexander Pastuhov
http://www.pastuhov.com.au/index.htm
 
Take a look at Document ID OFN-03-0015 on the KG. For ERP 8.0, SAR 6513122 addresses G/L post performance and allows for parallel processing. This is included functionality in 8.9 base. It is really great news for a lot of folks. We had major issues with our "single threaded" GL job queue and runube executing scheduled jobs in interactive mode on our UNIX enterprise server. When multiple post jobs ran simultaneously we experienced truncated data which then needed to be manually input by some very frustrated and rightfully upset users.

You've peaked my interest with your question. What exactly are you trying to accomplish? If it's the ability to run jobs in different environments on the same enterprise server to speed up testing, you could do as Alex suggested and change the version's default job queue. You could even get by without a server package build if you have a spec install queue running for the job queue in question. If these different environments have OCM's that point to the same set of Business Data tables, that might not be the best of ideas. If you ever plan on promoting these versions to an upper environment, you might run into some problems if you aren't careful to change the queue name back to it's original value. If this is indeed the scenario (running two environments on the same enterprise server) you might be better off if you install multiple foundations or obtain another UNIX box. The latter is obviously your ideal option. On the cheaper hand, multiple foundations would allow you to utilize the same queue name, simply on a different listening port. Both methods would allow you to get by without using separate job queue's for your R09801 versions. This is why the CNC concept really fascinates me. There are 5,000,000 ways to die, and you can choose more than one!

Charles
 
Wow, I thought I was the only one up this late trolling the message board! I agree with Alex, it would probably be too much to maintain. You might be able to script this with some clever usage of runube or runubexml and the "call external command" Business Function. It would probably require some report interconnects and a UBE "wrapper" to tie it all together. If you have read all of my previous post, decided that none of my points apply to your situation, give it a shot. The most you will be out is time, and you just might learn something along the way.

Charles
 
I understand where all ideas are headed.

However, we have 4 clients which need separate environments. They use the same enterprise server. They have separate business data. The only problem is if we bring on more clients then we have to add more versions the problem becomes exponential. Not only will we have to have more versions but new review applications. In the exit bar, the POST BY BATCH button is the most highly used. This is specific to the application. So we would have to create a custom app for each client so it uses the correct version to go to the correct queue.
We don't want 1 client to wait for something to post because the other is posting 300 batches.

Any more ideas?
 
Bill,

Thanks for clarifying your situation. One more question: is this a Citrix or Web client configuration? I am not a consultant nor do I run my own business...but this sounds like an excellent opportunity for you to charge the heavy-hitters more $$$ per CPU cycle! :)

Seriously, since there is no OCM category for versions, only UBE's, and the default job queue probably wouldn't be the best place to throw 300 post jobs, you might have but a few options if you can't justify multiple foundations, multiple servers, or additional hardware for your existing enterprise server. If you were running Windows, and had enough horse power under the hood, a product like VMWare GSX server would be a possible solution. You would be able to give each client their own virtual server and you would not be limited to the single job queue for the one version. Many commercial UNIX vendors sell hardware partitioning options for their mid-range and higher servers. This might be another avenue for you to investigate. HP is working on software VPAR's, but you increase the likelyhood of a single point of failure disrupting the other clients business.

Another more messy solution would be a Citrix configuration where each client ran out of their own patchode (per client - not per user) and you customized their JDE.INI's accordingly. You would set this up much like a remote development TSE, without the development option enabled, of course. This would allow you to modify the version in the local spec's to submit to whichever job queue you wish, so long as there is a spec install queue for that job queue name! Be warned: any time you deploy a new package to each clients path code directory, you would need to change the version to the desired queue name. Talk about a lot of extra work.
 
This is a Citrix config. We have only 1 pathcode. All the clients have their own data. We don't want to create 30 version per batch type per client.

The Post program (R09801) is the only one need to be changed.

Any other suggestions
 
Back
Top