This website is not affiliated with, sponsored by, or approved by SAP AG.

ALEREMOTE user gets locked because wrong password supplied

Business Warehouse

Moderators: Snowy, thx4allthefish

ALEREMOTE user gets locked because wrong password supplied

Postby mijas » Tue Mar 27, 2007 4:16 pm

This happens during the extraction from any datasource.
Source system check goes well. However, if you start doing any extraction, the extraction stops with the following error:

Errors while sending packages from OLTP to BI

Diagnosis
No IDocs could be sent to BI using RFC.

System Response
There are IDocs in the source system ALE outbox that did not arrive in the ALE inbox of BI.

Further analysis:
Check the TRFC log.
You can access this log using the wizard or the menu path "Environment -> Transact. RFC -> In source system".

Error handling:
If the TRFC is incorrect, check whether the source system is fully connected to BI. In particular, check the authorizations of the background user in the source system.


tRFC log shows following function modules:
RSAR_TRFC_DATA_RECEIVED
IDOC_INBOUND_ASYNCHRONOUS

with following errors:
Name or password is incorrect (repeat logon)
Password logon no longer possible - too many failed attempts


This when source system (R/3) tries to establish connection with BW.
ALEREMOTE user in BW therefore gets locked.
After you unlock the user manually and start another extraction again, it quickly gets locked again.

Our Basis people have checked and even re-created the RFC destinations, and they seem to work good. Even replaced ALEREMOTE user with the new one. Source system was re-stored and re-activated.

Nothing helped though.

Any ideas?
mijas
 
Posts: 13
Joined: Mon Feb 14, 2005 4:27 pm
Location: Calgary, Canada

Re: ALEREMOTE user gets locked because wrong password supplied

Postby toonvl » Mon Aug 22, 2011 4:37 am

Hi,

This has been posted a long time ago, but perhaps still of use for some so I'll answer anyway:

I've been having difficulties with RFC-connections lately and something I discovered was that along the way somehow the password was translated to uppercase, so in some cases when using a lowercase password for a user used in the connection it was translated to uppercase somewhere, and failed the check with the password set in the destination. But when using an uppercase password this problem does not occur.

Perhaps this is not the case, but I still reccomend using passwords of max 8 chars long in uppercase for users used for RFC connections, like was required in old SAP systems.
toonvl
 
Posts: 1
Joined: Mon Aug 22, 2011 4:29 am


Return to Business Warehouse

Who is online

Users browsing this forum: No registered users and 5 guests





loading...


This website is not affiliated with, sponsored by, or approved by SAP AG.