Summary
You
receive an error when you load data, during the transfer structure
maintenance, when you maintain InfoPackages or create or delete a source
system.
The error messages indicate an incorrect configuration in ALE and/or in the assignment of source systems and BW System(s).
Source system, transfer structure, scheduler, ALE
Cause and prerequisitesYou performed one of the following activities in the past:
- You changed the logical system names of one of the systems, which are connected to each other (with BW source system assignment or only with a RFC connection).
- Incomplete deletion and re-creation of a BW source system assignment.
- You copied a system with a database or client copy.
This
note describes step by step how you can check the status for your BW
source system assignment and, if necessary, repair it.
If you already know that one of the following cases exists, read the respective solution below:
- The logical system name of BW was changed after the source system had already been connected:
Solution 1.
- You cannot delete the source system:
Solution 2.
- The OLTP was created with a database copy via another OLTP which had never been connected to a BW System:
Solution 5.
- The OLTP was created with a database copy via another OLTP which had already been connected to a BW System:
Solution 6.
Checking the status:- Log on to your BW System.
- Call Transaction SE16, table T000. Note the logical system names of all clients (field LOGSYS), in particular of the BW standard client.
- Call Transaction SE16, table RSBASIDOC. All sender receiver relationships known to BW are stored in this table.
Check: Have all entries in field RLOGSYS the same logical system name as the BW standard client?
- If not: Is the logical system name of the BW standard client in the corresponding field SLOGSYS?
If yes, BW is used as a source system (DataMart) in this case.
If not, note the entry in field RLOGSYS and the respective entry in field SLOGSYS. Proceed as described in solution 1 - see below.
- If yes:
- Log on to the source system manually.
- Execute the above-mentioned steps for the source system (table T000, table RSBASIDOC). Note the following in this case:
There must be exactely one entry in table RSBASIDOC, which exists in fields SLOGSYS, RLOGSYS, BIDOCTYP, TSPREFIX, SRCTYPE, SAPREL which is identical in BW and in the source system. If this is not the case, proceed as described in solution 3 - see below.
The logical name of the source system (T000) must be equal to the name in field SLOGSYS in table RSBASIDOC. If this is not the case, adjust the logical system name to the name in field SLOGSYS (maintenance T000). However, note: As a result, you may destroy the successful connection if the source system works with another BW successfully. Proceed as described in solution 1, however, do not change the name of the BW, but of the source system!
Solution 1:The logical system name of BW was changed after the source system has already been connected. You have two options:
- Rename the BW System to its old name. This is the name which you just noted as entry in field RLOGSYS.
However, you can only do this if all systems have this entry in table RSBASIDOC in field RLOGSYS.
- Delete the source system. To do this carry out the following steps:
- In the Administrator Workbench change to the source system tree.
Does the corresponding source system have subnodes? If yes, note them down.
- Inform all users of the BW System, that they cannot load data at present. Ensure, that no loading jobs are running.
- Change to Transaction SM31, table T000, Maintain.
Position the cursor on the BW standard client and choose "Details".
Note down the current logical system name.
Enter the logical system name which you noted from field RLOGSYS and save.
- Change to the Administrator Workbench.
- If the source system has subnodes (InfoSources), delete the source system assignment in the InfoSource tree. Delete the source system in the source system tree. If you receive an error messages when you delete, read solution 2.
- After the successful deletion, enter the correct logical system name in table T000 again.
You cannot delete the source system. Two cases have to be distinguished:
- The source system still exists.
Switch to Transaction SM59. Find the destination which has the same name as the logical system of the source system from field SLOGSYS in table RSBASIDOC (see above).
- Such a destination does not exist in Transaction SM59. In this case, you have to create the destination to the source system. Name the destination equal the entry in SLOGSYS from above. Then return to the Administrator Workbench and repeat the deletion.
- The entry exists but a remote login is not possible. Correct the communication parameters.
- Everything works. Change to Transaction SE37, function module RSAR_LOGICAL_SYSTEM_DELETE, Sngl. test. Parameter I_LOGSYS = <log. name of the source system>, I_FORCE_DELETE = 'X'.
- The source system no longer exists or was replaced with another source system with the same IP address.
Proceed as described in the first case but make sure, that the field 'Target host' contains a not existing server in the maintenance screen of the destination (Transaction SM59). If necessary, change an existing entry. Later when you delete, the system asks you whether you want to delete, although the source system is not available. Select 'Ignore'.
Solution 3:The BW source system relationship is destroyed.
Try to delete the source system in BW. To do this, go to the Administrator Workbench, source system tree.
If the deletion fails, read solution 2.
After
the deletion (possibly after executing solution 2), delete the BW
definitions in the source system. To do this: Solution 4
Solution 4
In
the source system, change to Transaction se37, function module
RSAP_BIW_DISCONNECT, Sngl. test. Parameter I_BIW_LOGSYS = <Name in
field RLOGSYS in RSBASIDOC in source system>, I_OLTP_LOGSYS =
<Name in field SLOGSYS in RSBASIDOC in source system>,
I_FORCE_DELETE = 'x'.
The definition
of the BW source system connection still exists on the BW side;
however, on the OLTP side, however, no BW is connected. That means, the
table RSBASIDOC in the source system is empty.
You now want to reconstruct the BW - OLTP connection in the OLTP so that it corresponds to the definition in the BW System.
In the source system, call the following function module via Transaction SE37 - Single test: RSAP_BIW_CONNECT, parameter:
I_LANGU <Language of the connection in Transaction SM59>
I_SLOGSYS <OLTP Source System (SLOGSYS from RSBASIDOC in BW)>
I_LOGSYS <BW System (RLOGSYS from RSBASIDOC in BW)>
I_STEXT <Name of the OLTP system>
I_BASIC_IDOC <BIDOCTYP from RSBASIDOC in BW>
I_SAPRL <SAPREL from RSBASIDOC in BW>
I_RESTORE
I_TSPREFIX <TSPREFIX from RSBASIDOC in BW>
I_PREFIXE <35 times second byte of TSPREFIX from RSBASIDOC in BW
(for example, TSPREFIX = 'BA', then
I_PREFIXE = 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA')>
This solution describes how you can restore the connection existing in BW for the copy of the OLTP:
- If the original OLTP had already been connected to a BW System, you have to delete this connection in the OLTP copy on the OLTP side. To do so, execute solution 4 for all BWs that were connected to this OLTP.
- If the deletion was successful, give the same name to the OLTP copy that it had before being replaced by the copy. You can find this name in the BW System, table RSBASIDOC in the field SLOGSYS.
- Now carry out solution 5.
- In the BW System, activate all transfer structures for this OLTP manually in the InfoSource tree.
Header Data
| Release Status: | Released for Customer |
| Released on: | 13.08.2003 11:20:01 |
| Master Language: | German |
| Priority: | Correction with low priority |
| Category: | Consulting |
| Primary Component: | BW-WHM-DST-SRC Source Systems |
| Secondary Components: | BW-BCT Business Content and Extractors |
