cancel
Showing results for 
Search instead for 
Did you mean: 

Data Buffer error USER_AUTH_FAILED: User account for logonid "SYSTEM"

Former Member
0 Kudos

All, I have the following errors on both the Quality and the Production system in our data buffer job.

com.sap.security.api.NoSuchUserException: USER_AUTH_FAILED: User account for logonid "SYSTEM" not found!

These entries will not process because they are generating an error about the loginid for the Username SYSTEM is not found.

So I am thinking that somehow the MII system is not capturing the correct username when they are being added into the Data Buffer Jobs, or there is something I am overlooking when I set up the databuffering.

Other entries that were in the data buffer jobs were listed as using the RS1000SVC-QMUSBATCH, RS1630SVC-PMIIBATCH User accounts. These are the accounts that our scheduled tasks run under.

Those entries process OK out of the data buffer jobs.

I did notice a similarity between the data buffer jobs in the quality and production systems as it pertains to the following transactions.

Production MII ver 12.0.7 (Build 20)

Muscatine%2FIntegration%2FSAP%2FPROD_CONFIRMED_INPUT_InsertQuery

Which is called from the MIIC1043_IDOC Message Processing Rule.

Muscatine%2FIntegration%2FSAP%2FHEADER_InsertQuery

Which is called from the MIIC1043_Control_Recipe_Download Message Processing Rule.

Quality MII 12.0.11 (Build 14)

Muscatine%2FIntegration%2FSAP%2FPROD_CONFIRMED_INPUT_InsertQuery

Which is called from the MIIC1043_IDOC Message Processing Rule.

So the commonality is that these transactions are being initaiated by the Message processing rules.

Are there known issues with data buffering from transactions initiated with Message Processing Rules?

Is anyone sucessfully using data buffering of transactions called by message processing rules?

Any help is appreciated.

Bob

Accepted Solutions (0)

Answers (1)

Answers (1)

jcgood25
Active Contributor
0 Kudos

It appears as though the Insert Query templates that are being run inside your transaction are being run as the SYSTEM user and therefore not authorized by UME to run the template (ReaderRoles). I assume this would be the default identity of a system level job when run through the scheduler (assumedly the account configured for the running NW services), or a message processing rule (essentially any sort of background processing jobs).

If you have a user/pwd for the scheduled job and these buffer entries work, then have you considered categorizing the inbound message instead of calling the TRX directly. Then you can process it with a scheduled job (where you can key in the user credentials). Perhaps an extra step, but since there is no place to enter 'run as' user credentials in either the message listener or the processing rule, this might be a needed workaround.

Former Member
0 Kudos

Jeremy, Thanks for your reply.

There doesn't seem to be much detailed information on the use of Catagories with Processing rules in Help or in the forums. So let me see if I understand your suggestion correctly.

On the MII server create a processing rule for the message using a category instead of using a transaction, The message received by the message listener will be placed in a buffer. I am assuming these messages whould show up in the message monitor and not in the Data Buffer jobs/entries.

So in my transaction which normally processes this data I could add logic to access the message data; using the Message Service (Query, Read, Update and Delete) action blocks. I could pare down the selection by selecting messages based on the MessageCategory that I defined in the message processing rule. This will allow me to access the stored message data.

Finally use a scheduled Job to execute the transaction. The scheduled job would be run with a valid userID and Password so if it connection to the external database failed the enteries would be placed in the data buffer jobs with a valid userID credentials.

Does this sound like what you had in mind?

jcgood25
Active Contributor
0 Kudos

Yes, you have properly deciphered my suggestion.