Triggering workflow event from WE19 (Inbound)

Joyjit Ghosh, Kolkata.

We were trying to test a custom inbound function module where for error it triggers the workflow so that user can be send notification mails with details of the problem.

We were using transaction WE19 to test the FM, for that we had chosen Inbound function module option.

But in SWEL we had found that no event was raised by the FM.

But in our code we had populated workflow variables correctly

Also we had checked the config. and found that this FM is properly configured to raise the event INPUTERROROCCURRED.

After spending few minutes we were able to figure out the problem. We had observed that if we choose Standard Inbound option with ALE Service Check box checked then it triggers the event.

Note: Our custom inbound FM Z_IDOC_INPUT_GOODS_RECEIPT was attached with custom process code ZMIM_POGR.

SWEL:

Then what was the reason for not triggering the workflow? Reason is very simple; workflow is triggered by the ALE layer itself, without ALE layer we cannot trigger the workflow. So if you want to trigger workflow for inbound IDOC from WE19, choose Standard Inbound option with ALE Service Check box checked.

Error handling in LSMW

Joyjit Ghosh, Kolkata.

To do error handling in LSMW object we can write validation logic in step “5 Maintain Field Mapping and Conversion Rule”. All custom codes written in this section will be part of the conversion program once we generate it.

Following steps are required for error handling:

1. Define an internal table to store all error messages
2. Write logic to validate the data and populate the error table when validation fails
3. Display error messages as part of conversion program output

All these steps should be performed under step “5 Maintain Field Mapping and Conversion Rule” from transaction LSMW.

Step 1: Define an internal table to store all error messages

In __GLOBAL_DATA__ section define the internal table that will store the error messages.

Step 2: Write logic to validate the data and populate the error table when validation fails

Now write validation logic for the fields those we want to validate. If validation fails then populate the error table and after that call the macro “SKIP_TRANSACTION” so that this error record can be skipped and control will go to next record in the file.

Step 3: Display error messages as part of conversion program output

Now at __END_OF_PROCESSING__ section write logic to display the error table.

After writing the above steps, check the syntax of the custom code by clicking the appropriate button () on application toolbar. It will display a pop-up screen where we need to press ‘Yes’ button.

If everything is OK then it will display message that conversion program is regenerated successfully.

After this follow the LSMW steps like “7 Specify Files”, “8 Assign Files”, “9 Read Data”, “10 Display Read Data”. And lastly perform the step “11 Convert Data” where SAP actually executes the validation logic (written in step “5 Maintain Field Mapping and Conversion Rule”) as part of conversion program. And display the error messages those are generated due to error handling.

Output:

Guidelines to write a good Technical Specification

Joyjit Ghosh, Kolkata

Following points need to be remembered at the time of TS preparation.

• If Technical Specification template contains any instruction then we need to replace them with actual content. If nothing is required to fill against that section then put N/A (Not applicable) instead.
• Use consistent Font (Family and Size) throughout the document (e.g. Arial 10 or Times New Roman 10)
• The Technical Specification title should follow the naming convention that is agreed with the client like :"( Type of Development) : (Description of the Development)".
  Ex: Report: BOM explosion level by level.
• The Technical Specification file name should have an agreed naming convention like "TS_(Short Description)". E.g. TS_BOM_Explosion.doc
• Maintain Date and Version on the first page of TS
• Maintain Amendment History
• Maintain QA’s and Signoffs Section.
• Do not add anything in “Table of contents”, only you can update the page number.
• Don’t delete any section of the TS template; if no information is available for any section then put N/A instead.
• Maintain contact details of the developer and functional owner
• Provide all CTS numbers including dependent objects stored in other CTS.
• Mention all assumptions & issues; provide closure date with issue resolution for the closed issues
• Mention all technical details like Program name, Transaction name, Package name, Message class, and other repository objects correctly, they should follow the agreed naming convention
• If required Table access diagram should be created where all tables along with keys fields and their relationships are drawn correctly
• The flow diagram should describe the high level program flow. It should have a START node and an END node. Use the Flow Chart symbols to depict various steps.
• The pseudo code should be organized in paragraphs indented properly as per the flow logic.
• In the pseudo code each sentence should start with words like “Retrieve”, “Perform” etc.
  Example: Retrieve the following fields from table MARA
  Perform the following steps for each record of T_MARA
• In the pseudo code a SELECT statement can be written as:
  Retrieve the fields (Field List) from into an internal table (Say T_ITAB) using the following criteria.
  In the pseudo code a LOOP statement can be written as:
  Perform the following steps for each record of internal table T_ITAB.
  In the pseudo code an IF statement can be written as:
  Perform the following steps if is true or false.
  In the pseudo code data declarations can be written as:
  Declare the following variables. X1 type CHAR1
  In the pseudo code calls to function module can be written as: Call the function module and pass the following parameters to the function module. The parameters can be specified in a Table format or attached as an excel document.
  In the pseudo code for custom table, list of fields should be included along with the data elements, foreign key checks etc. Also Technical settings need to be specified along with Delivery and Maintenance details.
  In the pseudo code mention Selection Screen Criteria along with its data type, default value, mandatory, selection screen type and validations.
  Perform spelling check after the preparation of the document.
  Go to document Properties and fill the Summary tab with appropriate values.
  
• In Unit test plan (UTP) document all the test conditions appropriately
• In Unit test plan (UTP) expected results should be documented clearly
• In Unit test plan (UTP) test data should be given if available

Display background (water mark) image using SAPscript

Joyjit Ghosh, Kolkata

Detail Steps:

Step 1: Create a standard text (transaction SO10) and insert the background image in it

Step 2: Now open the layout set (transaction SE71) in which background image needs to be displayed and do the required changes as mentioned below.

Note: Here I am using an existing custom sapscript layout where all windows, pages and page windows are already created except the background image. And for this demo I am showing the changes required for inserting the background image in the 1st page.

Goto “Page window” of the 1^st page and create another page window of type ‘MAIN’. And its attributes must be same as the existing “MAIN” window.





Now open the Text Elements of the main window in edit mode and in the 1^st line of the Sapscript editor insert the standard text (created above) that contains the background image.

Now in the 2^nd line insert the special command NEW-WINDOW

Definition of NEW-WINDOW command:

Each page can consist of up to 99 main windows. Each main window is assigned a consecutive identifying number (0..98), and the windows are filled in this order. This feature enables SAPscript to print labels and to output multi-column text. When one main window fills up, the next main window on that page is taken, if there is a next one. A page break is inserted after the last main window.

You can use the NEW-WINDOW command to call the next main window explicitly, even if the current main window is not yet full. If you are in the last main window of the page, the command has the same effect as the NEW-PAGE command

Now activate the form

Step 3: Maintain required configuration for triggering the form

Step 4: Now trigger the form and see the print preview

Result:

Form is displayed with background image in print preview.

ALE Audit

Joyjit Ghosh, Kolkata.

You can configure the receiving system to generate ALE Audit messages for all incoming ALE IDocs for certain message types, and to send these messages to the sending system, where the ALE Audit toolset can use them to maintain a complete audit trail.

To enable ALE Audit:

§ Set up the ALEAUD message type in the Customer Distribution Model and Partner Profiles.

§ Define a filter object in the distribution model to specify the message type that you want to audit.

The data contained within the ALEAUD messages (IDOC type ALEAUD01) provides detailed status information on the IDocs in the receiving system, as well as the links between the IDocs and the resulting SAP application objects on the receiving system.

Audit IDoc Structure

These are the segments in an ALEAUD01 IDoc, with the fields they contain:

§ Segment E1ADHDR

o Message type

§ Segment E1STATE

o Sender’s IDoc number

o Current status

o Message fields

§ Segment E1PRTOB

o Receiver’s IDoc number

o Application object information

Two programs enable cross-system reporting.

§ RBDSTATE. This program is scheduled to run periodically on the destination system. It reports the status of incoming IDocs to the sending system, using the ALEAUD message and ALEAUD01 IDoc. This status information is recorded separately from IDoc status information in the audit logs.

§ RBDAUD01. This program is executed on the sending system. It analyzes the audit log and displays the output as a report.

Program RBDSTATE

Transaction: BDM8

Program: RBDSTATE

Use the program RBDSTATE on the receiving system to send the audit messages to the sending system, using ALE (I.e. asynchronously). You typically run this program as a scheduled batch job. The parameters of RBDSTATE are:

§ The sending system (of the original IDoc)

§ The message type

§ The date range the IDoc’s status was changed. Any IDoc having a status record in this date range will be confirmed.

The audit messages contain:

§ The current status of the inbound IDoc

§ The id of the resulting SAP application object (if the IDoc was
successfully posted)

The system will confirm up to 500 IDocs in one ALEAUD message. If
there are more than 500 IDocs to be audited, then it will create multiple
audit IDocs.

NOTE: The RBDSTATE program looks at IDoc status records to determine which IDocs to audit. If any status record was added to an IDoc during the specified date range, the program will audit the IDoc.

The RBDSTATE program returns the following statuses, from the receiving to the sending system.

Status of IDoc in receiving system	Status reported to sending system via ALEAUD
53 (Application document posted.)	41 (Application document created in receiving system.)
51 (Error: Application document not posted.)	Status 39 (IDoc is in the receiving system.) This status is repeated each time RBDSTATE is run, as long as the IDoc remains in status 51.
68 (Error: No further processing.)	40 (Application document not created in receiving system.)

Program RBDAUD01

Transaction: BDM7

Program: RBDAUD01

Use the program RBDAUD01 on the sending system to look at the ALE Audit IDoc statistics.

§ “IDocs total” is the total number of IDocs audited

§ “Queue Outbound” is the number of IDocs that have not yet been sent to the other system

§ “Queue Inbound” is the number of IDocs that are still being processed by the receiving system

§ ALE Audit records may be selected by message type, date range, etc. You can drill down into the report to see information on daily statistics, detailed information on IDocs, and cross-system links for successfully processed IDocs:

How to execute SOLMAN_DOCU_VERSION_DEL

Joyjit Ghosh, Kolkata.

Program SOLMAN_DOCU_VERSION_DEL is part of Solution Manager and purpose of it is to delete versions of stored documents. To run this program successfully we need to do following things:

In tran. SOLAR02 for a project when we upload a document it is stored in folder SOLAR00 by default (see the screen shot below), we need to change it to our project folder, ex: for project SARA_TEST9 all documents should be in the folder SARA_TEST9.

It can be done by clicking button beside folder field.

Now click on change button and then SAVE the document so that SAP generates separate version for every change

Here we have changed a web link (TEST) with status NOT_STARTED (Z001).

Now run the program with value shown in the screen shot:

As result we will get the status log: