Run UBE/Batch with different user

HI All,
I have a C BSFN that performs a jdeLaunchUBEEx, but I need the UBE not to be executed with the actual user that called de BSFN, but instead with some other user stored in a custom table, previously fetched. That new user will submit the batch and will be in the WSJ appl to filter.
I have tried modifying the lpBhvrcom structure but with no success so far.
I would apreciate any help from you. Thanks a lot.

I was able to do something pretty close (it requires the user & the password, among other things) with a lot of help from JDEList - you may find it in 2009 ...
Attached is the code.

Thanks Adrian!

How did you manage to have the passw available? I don't think theres a BSFN to get it . Anyway, what you did is pretty close to what I need. I will also try to solve that password issue.
Thanks a lot!

Thank THE JDE List Diego!

PS You know the basics: 'give a fish, it feeds a day; teach to fish, it'll feed a life ...' or something to that extent.

Read you later,

Diego,

another solution could be to use RUNUBEXML and the bsfn ExecuteExternalProgram.
For the password i think you should have a look on this :

There are two APIs available to encrypt and decrypt the data and the caller is responsible for providing and managing the key and storing the key in a BLOB field:

jdeEncryptWKey - jdeEncryptWKey performs encryption with input JCHAR string data and JCHAR encrypt key string, and then return encrypted bytes and its length.
jdeDecryptWKey - jdeDecryptWKey performs decryption with input encrypted data bytes and JCHAR encrypt key string, and then return decrypted JCHAR string with its length.

An example on how to use these APIs can be found in BSFN B0800800.C. This will help in developing custom application(s) related to password encryption in JDE.

We have the exact same thing here by using pre running subsystem jobs spawned under specific USER IDs.

Inbound EDI signals then go on to submit and wake up other UBES by adding a record to the susbsystem jobs (by using B4700270)

This is done for PPAT message checking and only certain users know the password for the generic user.

Seems a bit long winded and I'm sure there was a reason for it, but the important thing it works.

Hi guys,

A little birdie tells me that the ability to override the user at runtime is now a standard feature easily accessible from E1.
No need for any development?

I am on E9.0 so can someone on E9.1 kindly confirm this please?

Thanks

John