SAP EDI Process Restart with ALE Tools

If error occurs in EDI process of SAP we can use the method is an alternative to restarting the process from the SAP Inbox and is commonly deployed for mass errors, but you can also use this approach for single errors.

Scenario :Consider the following situation: If the file system has some problemsay that it's full or in accessible the dispatch program will fail in passing the IDocs from the SAP system to the EDI subsystem. A work item will be generated for every IDoc that fails. The number of such work items can be enormous, considering the number of IDocs typically exchanged in a company.

After you fix the problem, you can use the outbound ALE tool to restart all the failed IDocs in one step, without having to execute a work item for each failed IDoc in the SAP Inbox. You use transaction BD87 to bail out IDocs that are in error.

The transaction code is BD87 and the menu path for this is From the area menu for ALE Administration (BALE), choose Monitoring, Process IDocs.

The following are corresponding status codes of errors.

This tool allows you to process the IDocs from the point of failure without having to restart the process from the beginning.

The steps are

1.Execute transaction BD87. 1.
2.From the screen displayed as shown and fill in the selection criteria.

3.On the next screen you can select a summary line and click the Process button to reprocess all IDocs represented by the line. By clicking the Restrict and Process button, you are shown another selection screen to further restrict the number of IDocs to be processed.

And will be further presented in the coming posts.

The previous post deals with trouble shooting of edi with tools .

ABAP TOPIC WISE COMPLETE COURSE

BDC
OOPS ABAPALE
IDOC'S
Work Flow MM
Work Flow SD
Communication Interface

EDI Trouble Shooting for SAP part two

EDI trouble shooting for SAP in view of ABAP is the previous discussion this post is in continuation to that topic.

Restarting Message Control :

The restart from within the Message control can be carried out for applications that use Message control.

Automatically You can restart the outbound process from within the application document by going to the output control screen. You go into the document in change mode. Some output types are configured to be proposed every time you enter the document this way.

A new entry will exist with a current status of yellow, or 0, indicating that the entry has not been processed yet. The document can then be saved. The timing of the output type determines when processing will start.

To see whether an output type is proposed every time you go to change a document, go to the settings of the output type. If the Condition Access and Multiple Issuing flags are checked, the output type is configured for proposal every time. However, the output still might not be proposed if condition records and requirements are not satisfied.

Repeat Output

If your output is not proposed automatically, you can manually repeat the output from the output control screen by selecting the previously failed output and then clicking the Repeat Output button on the toolbar.

This step will create a new entry in the output type list. After you save the document, the timing of the output determines when the processing will start.

Output from NAST

You can also start the process from a NAST entry. This approach is possible only for entries that were once successful and were sent with a timing of 1 or 2 in the output type. This technique is useful when you have to send an output because it was lost or when you have to repeatedly test an output type. In this case, if you use the output control screen, it fills up very quickly and looks quite messy.

To start the processing, you execute the RSNAST00 program via SE38 or directly by executing transaction WE15. Enter the object key, which is your document number , and select the Send Again check box. Click the Execute button to restart the outbound process.

Restarting from the SAP Inbox

If a EDI workflow message was generated for the error, you have the option of restarting the process from within workflow. If the resulting screen has a Process button, restart is possible from within workflow.

Restarting from the SAP Inbox saves you the trouble of remembering the application transaction and data values. Remember, workflow brings the right task with the right information to the right person at the right time in the right sequence. You can simply execute the work item to start the process.

ABAP TOPIC WISE COMPLETE COURSE

BDC
OOPS ABAPALE
IDOC'S
BADI
BAPI
Syntax Check
Interview Questions
ALV Reports with sample code

If you are new to programming you can try data types of programming here.

EDI Trouble Shooting for SAP

In EDI of SAP there is a mechanism used to report problems at different points of failure . It is as follows.

1 . When an application document is created, the output control screen displays the proposed outputs. For any problems at this point, use the Determination Analysis option from the menu to identify the cause of the problem. No workflow is necessary.

2 . After the document is saved, control passes to the SAP system, and the processing of the output types starts asynchronously. The NAST table is processed for output types. Errors in managing the NAST entries are logged in the Message control table, but no workflow is started.

3 · The output type for EDI messages is processed by calling the IDoc selection program. Until an IDoc is created, the system cannot log the problems in the IDoc, so problems at this point are logged in the Message control tables. For applications that use Message control, you view this log from the output control screen.

If an error occurs in the IDoc selection program before an IDoc is created, the system sends a workflow message to the EDI administrator.

4 · After an IDoc is created, the system logs every problem in the IDoc's status records and then uses the workflow component to send a work item to the responsible person as identified in the partner profile.

5 · The system performs some basic integrity checks on the IDoc, as well as a syntax check. If an error is found, the IDoc gets a status code of 26 (Error during Syntax Check of IDoc Outbound).

A workflow message is sent to the responsible person as identified in the partner profile .Up to this point, any errors discovered in the system are categorized as ALE/EDI interface errors.

6 · The IDoc is then passed to the OS. Errors can occur for several reasons and are reported with a status code of 02 (Error Passing Data to Port). A workflow message is generated for the responsible person.

7 . After an IDoc is passed to the OS and the subsystem is installed, the system tries to start the
subsystem. Errors can occur for several reasons and are reported with a status code of 20 (Error
Triggering the Subsystem). A workflow message is generated for the responsible person .

EDI Outbound Errors for SAP :

The final success milestone depends on whether the subsystem is installed for EDI outbound process.
Subsystem not installed: If the subsystem is not installed, the process is considered a success when the IDoc generated for your process gets a status code of 03 (Data Passed to Port OK).

Subsystem installed: If the subsystem is installed, the final status code depends on the various statuscodes reported by your subsystem. The subsystem can be set up to send one final confirmation at the end or to report status at every milestone, in which case there can be several status codes in an IDoc.

The milestones are based on typical EDI translator processing. When the IDoc is initially received by the subsystem, the subsystem checks for critical control information, such as the partner and type of message. If these are valid, they tell the subsystem which translation procedure, or "map" to use.

The subsystem then translates the IDoc into a standard EDI document. It then checks the syntax of the document. If all is well, the document is wrapped in an interchange envelope, usually with other documents of the same type for the same trading partner, and dispatched through a network.

When the interchange is received by the trading partner, the trading partner's EDI translator returns an acknowledgement confirming receipt. From SAP's perspective, the process is successful if you get a status code of 18 (Triggering EDI Subsystem OK).

The following table gives the error codes for SAP EDI outbound process.



The previous post of SAP ABAP deals with System logs and analysis of SAP.

ABAP TOPIC WISE COMPLETE COURSE

Script Controls
Smart Forms
Work Flow
Work Flow MM
Work Flow SD
Communication Interface

If you are new to programming you can try data types of programming here.

Request you to subscribe for RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

SAP System Logs and Analysis part two

In The SAP system we have different system logs and this are further available SAP system logs.

The audit analysis for a destination system allows you to

1.Monitor the processing state of IDocs from the sending system ·

2.Monitor IDocs currently being processed on the sending system ·

A standard program, RBDAUD01 (transaction BDM7), is provided to display entries in the audit log. On the selection screen of this program, you can choose the logical system name of the destination system, message type, and creation date of IDocs.

The output shows IDocs in process on the current system for the destination system and IDocs in process on the receiving system.

You double−click any line to display detailed statistics.

Use the SAP Inbox

You will notice that when you execute a work item, it takes you to a log that you can also view without using workflow.

For example, if you have a work item for an application error in the IDoc, it takes you to the IDoc display screen where you can look at the error. By now, you're probably wondering why you use workflow when you can get to the IDoc display directly using transaction WE02 or WE05.

Workflow notifications are useful for error situations that can be predefined, but where the timing of errors is unpredictable. For example, the problem with the file log is very rare, so the system administrator will not be monitoring the log on a regular basis.

Workflow monitoring is also suited for people who are not frequent users of the system. The advantages of using workflow are timeliness and accountability for resolving the problems.

System administrators are interested in the overall state of the system and are more tuned to using the tools directly for everyday repetitive tasks.

For example, the EDI administrator will most likely be monitoring the IDoc list for errors to get a global view of the problems in the system. The information that administrators need cannot be defined concisely. Also, they have to monitor a wide range of errors.

ABAP TOPIC WISE COMPLETE COURSE

BDC
OOPS ABAPALE
IDOC'S
BADI
BAPI

SAP System Logs and Analysis

This is in continuation with SAP System logs and the previous post is about work load analysis on SAP system.

System Log

The transaction code for SAP system log is SM21 and the menu Path is From the main menu, choose Tools, Administration, Monitor, System Log.

The system log is a very comprehensive log maintained on each application server and possibly copied to a central log. This log records all system events, such as system startup, shutdown, process terminations, system errors, and communication problems.

This universal log is used by all the application modules and is typically monitored by the Basis administrators. Because of the universal nature of this log, the entries can be cryptic and are best analyzed by a Basis person in conjunction with the application person.

If you experience any unexplainable behavior in the ALE/EDI system, there is a good chance that something has gone wrong and is logged in the system log. Figure below shows an example of entries in the system log.


Transactional RFC Log

The transaction code is SM58 and the menu Path is From the Area menu of ALE (BALE), choose Services, Communication, Transactional RFC, Display Incorrect Calls.

tRFC (Transactional RFC) is SAP's enhanced asynchronous communication concept in which delivery of data is guaranteed. If network problems or any other conditions prevent data from being transferred, SAP holds the data and information about the remote system in the tRFC tables and attempts to deliver the data based on the configuration settings in the tRFC destination. This tool is used mainly in the ALE process.

A standard program, RSARFCRD (transaction SM58), is provided to display entries in the tRFC log. On the selection screen, the User Name field defaults to your user ID, but you can clear it to see tRFC entries for all users. The output report shows entries that are in error.

Column 1 (Caller) : The user who initiates the ALE process.

Column 2 (Function Module) : The RFC function module that is to be invoked on the destination
system. The RFC function module for ALE processes is INBOUND_IDOC_PROCESS.

Column 3 (Target System) : The name of the destination system.

Column 4 (Status Text) : A short description of the problem. You can double−click this text for extended information. In most cases, the problem is due to an incorrect user ID or network connection. Check your tRFC destination.

Some additional fields are not visible on the screen; you have to scroll to the right to see them.These display administrative information such as date, time, and the calling program's name. This information is useful only for identifying the process that made the tRFC call. It does not have any value in debugging the problem.

ABAP TOPIC WISE COMPLETE COURSE

BDC
OOPS ABAPALE
IDOC'S
BADI
BAPI
Syntax Check
Interview Questions
ALV Reports with sample code
ABAP complete course
ABAP Dictionary
SAP Scripts
Script Controls
Smart Forms
Work Flow
Work Flow MM
Work Flow SD
Communication Interface


Request you to subscribe for RSS FEED or get the updates directly into your mail box through EMAIL SUBSCRIPTION.

Work Load analysis on SAP System part two

previously How SAP systems adjusts the work load on it we have discussed and this is the continuation to that post.

Asynchronous Update Log:

Most applications use an asynchronous update method to speed the response time for end users. When an application document is saved, the data is stored in intermediate storage and then transferred to the database by asynchronous update processes.

For outbound ALE/EDI processes, the IDoc selection program in many cases is started in the update routine. Syntax errors in the selection program or other hard errors can cause the update process to fail and result in a dump. In this event, the system maintains an update log .

Usually, the Basis group or a programmer who is testing an IDoc selection program monitors this log. For detailed information,double−click the error line.

The Transaction code for this is SM13 and the menu Path is From the SAP standard menu, choose Tools, Administration, Monitor, Update.

An express mail is also sent to the user, informing him or her about the error. If you have written IDoc selection programs for the ALE/EDI interface, you probably remember receiving an express mail saying that the update was terminated when an error occurred in your selection program.

SAP System Dump Analysis:

This log maintains a list of dumps ( a log of program crashes). You can view this log to resolve any dumps described in the preceding section. The dump report is highly technical and is used mainly by a programmer developing IDoc programs.

we can use it when the system behaves mysteriously and everything looks fine. The reason for the mysterious behavior is obvious: The program crashed and did not have a chance to log any information. The dump analysis report in the SAP system is far superior to similar reports .

The report provides several leads to help you determine the cause of the problem, and also shows you the line of code where the failure occurred.

The transaction code for dump analysis is ST22 and the menu Path is From the SAP standard menu, choose Tools, Administration, Monitor, Dump Analysis.

We will continue discussing the SAP logs in the further posts.


Work Flow MM
Work Flow SD
Communication Interface

Work load analysis on SAP System

While working with SAP systems we shall analyze the load in the ERP and proceed.This article deals with the concept of workload on the system.

The workload analysis report monitors load on an organizational object such as user, position, job, or work center. The only restriction is that work items have to be executed and completed from within the workflow.

If they are completed outside the workflow, the system does not have visibility into the person who carried out the task. The selection parameters of this report allow you to restrict the output by type of organizational object, completion date, and task . The output is a report showing the work items that have been completed by the user.

The Transaction code forwork load analysis is SWI5 and the Menu Path is From the Area menu of workflow (SWLD), choose Reporting, Workload Analysis.


System−Level Logs

The system maintains log information for critical errors related to technical problems, such as problems with the network or the file system. A functional user is not involved in analyzing or resolving these errors.

The main users are the system administrators responsible for maintaining the system. The EDI administrator will most likely be involved with these tools at some point. The ALE/EDI programmers also interact with these tools during the development and testing phase.

Input File Log

The Transaction code is WE08 and the menu path is From the Area menu of EDI, choose IDoc, Display Status, File Interface.

A file log is maintained in the EDI process to log any problems in reading or deleting IDoc files on the inbound process. The inbound process maintains this log, stored as table EDFI2, to avoid processing the same file twice in case of an error. The EDI administrator is notified when entries are created in the file log.

The system maintains the file name and the last record read successfully from the IDoc file. The system also records the last IDoc number generated from the file. The EDI administrator has to edit the incoming file manually, by looking for problems near the record number recorded in the log, copying into another file the records that have not been processed yet, and then starting the process again.


SAP definition,full form,over veiw and introduction
SAP Full form of planning and distribution of goods
SAP full form for mrp,sales and materiel planning
What is SAP and Why do we are in need of It

SAP Work Flow Display for EDI and ALE

The workflow management system maintains an extensive log of all the activities carried out in the workflow system. From the time a work item is created to when it's completed, it goes through several steps.

A log documents each step, along with any vital information. The two tools described next help you retrieve the logged information in a useful and presentable format. The tools are mainly used by the EDI administrator to view the state of work items and the duration of the process . This report can help you identify bottlenecks and the source of any major problems.

Work Item Analysis:

The work item analysis reports are comprehensive reports for determining the state of work items in the system. We can execute these reports for the following information.

1.The number of work items created in the system and their statuses
2· The time it took to resolve the problems

The selection parameters list allows you to restrict the number of entries returned to you. You can restrict them by time or process type.

For example, if you're interested only in invoice IDocs that have failed in the past month, you use the task number for invoice IDoc as the restricting criteria. You press the F4 key on the task field and enter the task abbreviation (Invoic_MM_er). The system will return the task number.


we are mainly interested in the frequency (SWI2_FREQ) and process duration (SWI2_DURA) reports. The other report is mostly used for SAP business workflow processes.

The frequency report output is a summary of work items by task. You can drill down from this display to a list of work items that have been generated in the system based on your selection criteria. You can drill down to display the status of these work items. Further, you can drill down to each work item to get the details, such as the person who has it and the IDoc number associated with the work item.

The output of the process duration report is a time analysis of the completed work items for the selected period. You can toggle between average values and threshold values on the output report. The threshold values report provides a breakdown by percentage of items completed in the given time period.

A value of zero means that the IDoc was processed in a negligible time period. This report gives you an idea of how long it took to fix an error, from the time the user saw the error until it was finally resolved .

The previous post deals with IDOC TOOLS.

ABAP TOPIC WISE COMPLETE COURSE

BDC
OOPS ABAPALE
IDOC'S
BADI

EDI ALE IDOC tools for displaying information part three

Previously we have discussed about SAP ALE IDOC tools and this is in continuation with that post.

The output is a tree structure of IDocs sorted first by direction (inbound or outbound) and then by status codes . IDocs in error are displayed with red icons, IDocs with a warning are yellow, and successful IDocs are green. We can double−click any line to display the IDocs with that status code. A list of IDocs for the currently selected tree node appears in the list window to the right of the tree display.

IDoc Statistics

The IDoc Statistics program provides a report on the overall status of all the IDocs in the ALE/EDI interface. This program generates an output of IDocs that match your selection criteria. The selection parameters of this program allow you to restrict the number of IDocs that are selected. The default is all IDocs.

Transaction code is : WE07

Menu Path is : From the Area menu of EDI, choose IDoc, IDoc Statistics.

The output is a report of all the IDocs by status groups. A status group is a number that represents a list of status codes that have been grouped together to represent a particular type of error.

For example, status group 6 represents errors in the subsystem. In table TEDS3, you can see a list of various status groups and the status code included in each group.

By looking at the output of this report , you can tell how many IDocs are in the EDI subsystem, how many are in error, how many are awaiting dispatch, and so on. You double−click any box to
display the list of IDocs in a particular status group. From the list, you can drill down to a specific IDoc.

ABAP TOPIC WISE COMPLETE COURSE

Work Flow
Work Flow MM
Work Flow SD
Communication Interface