ALE Recovery

Cay Rademann
SAP AG
SAP AG recovery.ppt 01/1997/ 1

Consistency within one system

Concept of Logical Unit of Work (LUW)
The application document and the IDoc get posted on the database in the same LUW Consistency ensured by database

IDoc status
After each processing step the IDoc gets a new status Restart on the actual status

SAP AG recovery.ppt 01/1997/ 2

ALE Recovery
3 possible kinds of error:
I. Communication error The communication line is down. II. Hard loss e.g. disk crash The system halts when the error occurs. III. Soft error User made important data useless The database ran for an indefinite time after the error occured, but the system must be brought back to a status before the error.

SAP AG recovery.ppt 01/1997/ 3

Error I: Communication Error

The IDocs that have to be sent are waiting in the RFCqueue When the communication line is up again, these IDocs will be sent from the queue This is done by scheduled batch jobs (generated automatically or RSARFCEX)

SAP AG recovery.ppt 01/1997/ 4

Recommended TRFC Set-up

Turn off automatic creation of batch-jobs for communication errors for all destinations used for ALE communication. Schedule the report RSARFCEX als a batch-job, to resend TRFCs with communication errors. Make sure that all status except currently being processed are active in the variant of the batch-job.

SAP AG recovery.ppt 01/1997/ 5

Preconditions for Error II und III

continous backup concept DB permits point-in-time-recovery
Point-in-time-recovery is possible for all databases that support R/3 System from R/3 3.0D. For some databases, a point-in-time-recovery is possible since R/3 3.0A.

SAP AG recovery.ppt 01/1997/ 6

Error II: Hard loss

A database recovery restores the system. No data loss occurs with a continuous backup concept in operation. Outbound messages:
No messages are sent until the recovery is complete.

Inbound messages:
The messages are waiting in the queue of the sending system until the receiving system is available again.

SAP AG recovery.ppt 01/1997/ 7

Error III: Soft Error

Error at time T (e.g.: a user deletes all orders) At time S (S > T) the error is recognized and the system is stopped Point-in-time recovery for a time < T All usefull transactions between T and S must be repeated. External interactions may be duplicated
in some cases with different key (document number).

!!! Worst

Case !!!

SAP AG recovery.ppt 01/1997/ 8

Problem Description
System A has to be set back to an earlier status, time T (Point in Time Recovery)
System B has got IDocs from A, sent after T System B has sent IDocs to A later than T

System A

System B

SAP AG recovery.ppt 01/1997/ 9

General Procedure
Available with 4.0
System A
1. Start (synchron) 2. Recovery Audit 3. Create list of missing IDocs; Write Status according Audit message; Cancel tRFC-Queueentries 4. List of IDocs and application documents to be cancelled; Resend IDocs

System B

SAP AG recovery.ppt 01/1997/ 10

Differentiation: A -> B
ABT. Transactional data: new documents have been created in B, original documents do not exist in A any more
This affects both business documents and IDocs

ABR. Master data / replicas: Copies of objects have been created in B, they differ from the originals in A ABI. After the recovery IDocs exist both in A and B, but the IDocs have not been sent from A

SAP AG recovery.ppt 01/1997/ 11

Differentiation: B -> A
BAD. Messages that depend on a previous message from A to B
E.g.: ORDRSP (order response) from B -> A depends on the message ORDERS (order) from A -> B

BAM. Messages, that are independent of messages from A -> B

SAP AG recovery.ppt 01/1997/ 12

Treatment: Case ABT (Transactional Data)

Event: delta 4711: n -> 4711: n+100 after Recovery: 4711: n

A:
T

I1: + 100 S I2: + 100 I2: + 100 4711: n+100

B:

4711: n+100

Documents in B that depend on documents in A, which have been created after T, have to be canceled You can find these documents by looking at the IDoclinks

SAP AG recovery.ppt 01/1997/ 13

Treatment: Case ABR (Replicas)

Event: change 4711 -> 4711 I1: 4711 T I2: 4711 S I2: 4711 4711 after Recovery: 4711

A:

B:

4711

Objects, that have been replicated, have a newer version in B than in A They have to be sent again

SAP AG recovery.ppt 01/1997/ 14

Treatment: Case ABI (IDocs in communication)

Event: 4711 after Recovery: 4711 I1: 4711 T I2: 4711 S I2: 4711 4711 Status: 30

A:

I1: 4711

B:

4711

ABI - IDocs not sent at T

IDocs, that have been created in A before T but sent after T, may not be resent. They have to get a new status corresponding to what has happened on system B

SAP AG recovery.ppt 01/1997/ 15

Treatment: Case BAM (Independent Messages)

Event: 4711: n+100 after Recovery: 4711

A:

I1: + 100

T I2: + 100

S -> 4711: n+100

I2: + 100 4711: n+100

B:

4711

IDocs that have been sent to A after T have to be resent Change the status of these IDocs to 30 (IDoc ready for dispatch (ALE service)) and start resending (RSEOUT00)

SAP AG recovery.ppt 01/1997/ 16

Treatment: Case BAD (Dependent Messages)

Event: 4711 4712 I4: 4712 S I2: 4711 I3: 4712 4712 I2: 4711 I3: 4712 4711 4712 after Recovery: -

A:
T

I1: 4711

B:

4711

IDocs that depend on messages, which are dependent on other messages sent after T, may not be sent / resent They have to get a status for deletion (e.g. 31) and have to be taken out of the TRFC-queue if necessary

SAP AG recovery.ppt 01/1997/ 17

Determination of Affected IDocs

1. Recover system A; turn off batch-jobs 2. Start tRFC IDoc-status report 03 -> 12 (RBDMOIND) 3. System B: determine all IDocs with system A as sender or receiver that have been created in B after (T - Td) local time
Td corrects differences between the system clocks

4. ABT, ABR, BAM, BAD: all IDocs in B, for which the linked IDoc in A does not exist 5. ABI: all IDocs in B, for which the original IDoc in A has not been sent
In A: Status = 03 or earlier. At status = 03 the entry has to be removed from the tRFC-queue
SAP AG recovery.ppt 01/1997/ 18

Determination of Affected Documents

ABT, ABR: the documents are linked with the IDocs in system B BAD
With the help of the list of documents that have to be cancelled in B (ABT) you can create a list of those IDocs that may not be sent again from B -> A: Messages, that directly depend on cancelled objects (e.g.: ORDRSP), can be found by the links to the cancelled objects Messages, that are not directly linked, have to be investigated manually (at the moment there do not exist any messages of this kind in ALE scenarios)

SAP AG recovery.ppt 01/1997/ 19

How to Change the IDoc-Status?

You have to write your own report for changing the status of an IDoc This report can use the function module IDOC_STATUS_WRITE_TO_DATABASE You can write an error text to the new IDoc-status, that will be displayed in the IDoc-monitoring
Message type, Message ID, Message number, Message parameter

The following status may be used for

30 31 resending an IDoc IDocs that shall not be sent/resent

SAP AG recovery.ppt 01/1997/ 20

How to Investigate Links?

You can see the IDoc-links from the control record
Goto -> Links

The links are written to the table SWW_CONTOB

OBJTYPE: type of the object (e.g.: IDOC, TRANSID, BUS1001, OBJKEY: WI_ID: Element: LOGSYS: others... number of the object ID of the link (e.g.: SOURCE_IDOC, OUTBOUND_OBJECT, INBOUND_IDOC, ...) logical system that owns the object

Function module SWW_WI_READ_CONTAINERS_ OF_OBJ helps to find links

SAP AG recovery.ppt 01/1997/ 21