Ansicht
Dokumentation

SAPLV56P - Log Entry in the SD Shipment Document

General Data in Customer Master   CL_GUI_FRONTEND_SERVICES - Frontend Services  
This documentation is copyright by SAP AG.

Functional group V56P: Log management

Thd functional modules of this functional group serve in the collection of log entries which can be transmitted during processing.

Collect messages in the log

The log entries are messages of the ABAP which are normally transmitted with the MESSAGE command. These messages are stored in the global table PROTOCOL in the memory of this functional group (PROTOCOL has the structure SPROT_U).

With functional module SD_SHIPMENT_PROTOCOL_APPEND, an entry is appended to the log table.

Activation of the log

This happens, however, only if the log is active. Log management is activated via the functional module SD_SHIPMENT_PROTOCOL_START and deactivated with SD_SHIPMENT_PROTOCOL_STOP. Normally, the log is inactive.

Processing the log table

The log table can be picked up with SD_SHIPMENT_PROTOCOL_GET. SD_SHIPMENT_PROTOCOL_REFRESH initializes the log table in the memory of the functional group. With SD_SHIPMENT_PROTOCOL_PUT, one can directly fill the log table with entries.

In some applications, it is necessary to export the log into memory and then to pick it up from there, for example, if, in the framework of incoming processing (see Docu for functional group V56E), a CALL TRANSACTION VT02_MEM is executed. In this case, the log - which exists at "the save" - is exported into memory with SD_SHIPMENT_PROTOCOL_EXPORT. The log is picked up with SD_SHIPMENT_PROTOCAL in the calling program after the return from the transaction.

Log output

Log output can be carried out with SD_SHIPMENT_PROTOCOL_OUTPUT. For more information, see Docu on functional module SD_SHIPMENT_PROTOCOL_OUTPUT.

In the framework of log output, it is also possible to branch from the log into the processing of one of the documents mentioned in the message line (currently, delivery, shipment and freight charges are supported). The interpretation of the message line and the branching into the respective transaction happens in SD_SHIPMENT_PROTOCOL_DOC_SHOW.

Level in logging

Log entries can be transmitted on various levels. I.e., in the log table PROTOCOL, the field LEVEL is filled with different values (between '1' and '9').

This LEVEL influences the output of the log iwht functional module SD_SHIPMENT_PROTOCOL_OUTPUT.

On the top level (LEVEL = '1') only one message should be transmitted which presents the title of the log (e.g., 'Log for collective run no. 000002345').

On the next level, the important steps of the transaction are stored (e.g., 'Read deliveries', 'Generate shipments', 'Save shipments', etc.).

Below, detailed messages ('Delivery 0080001234 was selected') follow, with additional information on even lower levels.

The level of a log message can either be specified directly with SD_SHIPMENT_PROTOCOL_APPEND or taken from the global variable G_LEVEL if, at the call up, one specifies I_GET_GLOBAL_LEVEL = 'X'.

G_LEVEL can be set to a concrete value with SD_SHIPMENT_PROTOCOL_LEVEL_SET. With SD_SHIPMENT_PROTOCOL_LEVEL_INC, the value is increased by 1, with SD_SHIPMENT_PROTOCOL_LEVEL_DEC, de- creased by 1. With SD_SHIPMENT_PROTOCOL_LEVEL_GET one can ge the current value.

The output of a log with this technique is easily surveyed. At the beginning, only an overview is displayed with 'Main messages' and one can always click to go deeper.

Certainly, in such a case, it makes sense to see a message at the top level which says that there is an inconsistency farther down.

• Output of a message text which states that, in a subordinate transac- tion, an error occurred.

• The (neutral) message text remains the same, but the error gravity is changed (e.g., to 'E').

Regarding these two approaches, see the two following chapters.

Setting marks in the log

One can transmit a message at the top level stating that something went wrong (e.g., 'Some of the selected deliveries are blocked' instead of the neutral 'Selection of deliveries' message).

However, this message must appear in the log BEFORE the actual detail message. In the program run, this result is available only AFTER the execution of the transaction.

With SD_SHIPMENT_PROTOCOL_SET_MARK, one can make a type of pseudo-entry in the log. Then the actual messages of the transaction come ('Delivery 0080001234 selected' and 'Delivery 00800001235 is blocked'). Now one knows the entire result and can transmit the superior message with SD_SHIPMENT_PROTOCOL_APPEND and at that location previously marked with SD_SHIPMENT_PROTOCOL_SET_MARK. This happens with SD_SHIPMENT_PROTOCOL_APPEND whereby the parameter I_MARKER_GET = 'X' must be set.

With SD_SHIPMENT_PROTOCOL_DEL_MARK läßt, a marking of such a type can be deleted.

Marking is executed in a level-dependent way since even subtransac- tions, in turn, can have an overall result coming from their detail steps.

'Severity Transfer'

Often it is sufficient not to change the text of a superior message but rather to specify another error severity if something went wrong in subordinate transactions.

Example:
In selecting deliveries, one delivery in 15 is blocked. The superior message, 'Selection of deliveries' contains the severity 'E' (error) because, in one of the subordinate transactions, an error occurred.

In the hierarchical log output, this message is then indicated with by a red icon as an error. One recognizes immediately: In the selection of deliveries, an error occurred. By expanding the hierarchy tree, one can see the subordinate transactions and can recognize that the sixth delivery was blocked. With each of these subordinate transactions, the same thing could occur: It consists of partial transactions from which one produced an error.

Example:
In generating shipments, something was unsuccessful because the third leg of the fifth shipment refered to an invalid destination.

The message 'Destination: Connection point is invalid' is transmitted far below in the hierarchy tree. The superior message 'Creation of leg 3', therefore, contains the SEVERITY 'Error'. As a consequence, 'Creation of shipment 5' is also incorrect. The entire transaction 'Creation of shipments', therefore, is incorrect as well.

The error severity transmits itself, therefore, to the superior hierarchy levels. Hence the name SEVERITY-TRANSFER.

This SEVERITY-TRANSFER can be undertaken subsequently via interpreta- tion of the log. This happens in the functional module SD_SHIPMENT_PROTOCOL_PREPARE. The transmission of messages in the coding is simplified: One simply transmits only his/her message to the upper levels (without SEVERITY = 'E').

If an error occurs 'far below', one need only transmit an error message to the associated level and the superior messages automatically contain this error severity if one edits the log with SD_SHIPMENT_PROTOCOL_PREPARE.

Addresses (Business Address Services)   rdisp/max_wprun_time - Maximum work process run time  
This documentation is copyright by SAP AG.

Length: 7888 Date: 20240601 Time: 173259     sap01-206 ( 136 ms )