Submitting UBE under a different user - REVISTED (JDB_InitEnvOver API)

johndanter

johndanter

Legendary Poster
Hi guys,

Some of you may remember this thread?

http://www.jdelist.com/ubb/showflat.php?Cat=0&Number=140563&page=1&view=collapsed&sb=5&o=&vc=1

This is basically a nifty way of getting the JDE system to launch a UBE under a user of your choice using a nifty little API. It works great.

However I have made a twist to this in that I get a subsystem running user A to launch jobs under User B as I wish. Also works great!!!!

(A clone of B4700260 to simply use the new passed Huser2 in JDB_InitEnvOvr and not Huser running the BSFN)

However.......

What I am experiencing is User B seems to be possibly 'caching' the Work Centre somehow.

Now all UBEs using that subsystem (running under User A) even though they run in WSJ under User A, end up sending Work Centre messages to User B even though I haven't activated the switch......?

Very very odd.

Anyone any ideas as I'm at a loss

Thanks

John
 
I think we know why this is happening......?

When a subsystem restarts, whoever the first user call to the workcentre maybe, their 'account' with the work centre is remaining open. So all subsequent jobs spawned from that subsystem all go to the same work centre, regardless of the user running the UBE
frown.gif


Does anybody know of a good UBE that uses PPAT messaging?

Our idea is that the PPAT messaging isn't being closed properly....?

Is anyone else trying this kind of approach?

Really, all we want is for EDI UBEs to be called and run under different users (one for each signal for each site) so the work centre messages are easily traceable

Thanks

John
 
It's a tough one to explain, so let me try. The patient among you, please read on
smile.gif


We have 9 inbound/outbound EDI signals/UBEs. At present all are invoked via a BSSV calling a BSFN to write a record to launch a subsystem job.
That subsystem job then calls UBEs to do the EDI work.

The 9 subsystems are run under 9 specific users so we have 9 Work Centres for support purposes. This works fine as the UBEs called end up in the specific 9 WCs.

Great stuff. Works fine

But.......
all that was setup for one site. We now have another site coming online and want to split the WC messages out to different users WCs for the new site.
Initial reaction was just to create 9 new subsystems and carry on as normal. I feel this setup can't go on as we'll end up with loads of subsystems!

All this was designed and agreed before I joined. So I was asked to look into it, see if I can make it better.

so.....I copied B4700270 and used the API JDB_InitEnvOvr and JDB_InitUser to force the hand of the user who will end up calling the UBE by manipulating Huser.
(I have to save the new site users passwords in a file and pass it in)

I either call B4700270 or my B57001 to launch the UBE, happy days

This works great!!!! I can override the user who runs the job, or not and just let the subsystem call the UBE as for the first site user.

Thing is the subsystem thread seems to be opening a gateway to the workcentre and it 'locks' it. So any other jobs called after this 'lock' seem to end up with msgs in the locked WC even though WSJ clearly shows the override user who run the job.

So all this is beyond me. I can see what's happening and kind of think why, but I have no idea how to prevent the WC from staying open once the B4700270 does it's stuff.

You will see all the free user free env at the end of my BSFN that doesn't appear to be in the base BSFN.


Also, if my BSFN is launched via the BSSV with 3 jobs in succession (all override user requests) All 3 jobs WILL run as the overide user but only the 1st job goes to the new WC, the 2nd and 3rd default back to the old sites WC......?

It's that last statement that confuses me as if I call the jobs individually using my BSFN, they don't 'lock' the WC and we can switch all day happy as Larry.


Most odd behaviour.

So, any ideas.............................?
 
Hi guys

I was just wondering if any of you had ever done anything similar to this and got good results?

We are finally getting to testing this (a year on) and whilst my mind took a while to gear up and remember the issue, I developed a fix.

My fix was simply to get the BSFN WC calls to actually pass in the user.

It's not working as I would have expected.

So anyone?
 
Back
Top