SAP Authorization and ALE

SAP Authorization and how it is used while implementing ALE is the main discussion of the present post. Data is exchanged between systems utilizing ALE know-how with transactional RFC. The objective is to ensure the consistent distribution of information among all methods, even in the case that a part system is temporarily unavailable.

Steps for Configuring ALE

The following are the required steps for configuring ALE as a way to use CUA:

1. First, the title of the element methods must be known; the Office server must know the title and location of each part system. Likewise, every part system must know the identify of the Office server.
2. Because the communication is established utilizing RFC calls, the RFC connections must be outlined in each part system that can take a part of the mySAP landscape.
3. Inside the WPS, the ALE distribution mannequin have to be defined. This model defines which data (data sorts) is exchanged and among which methods that is performed. It defines how many techniques exist, how the information flows, and the documentation between them.

ALE Configuration

The programs that participate in the mySAP Workplace panorama are defined within an ALE situation based mostly on an alias, which is defined using logical systems. A logical system corresponds exactly to one shopper within a SAP system. For each system and shopper that ought to be enabled for connection, a logical system have to be defined. This definition is consumer particular in order that the client is immediately associated to the logical system. Throughout the Office server, all component programs need to be outlined as logical systems. Within the part system, the identical system and the WPS system have to be outlined as logical systems. The next step is to assign the logical identify to the purchasers, which is completed utilizing normal transaction for consumer upkeep such as the SCC4. For outlining the RFC connections, the transaction SM59 is used. Determine 5-9 reveals an summary of transaction SM59.

As a consequence of the WPS might need to join to every component system, all RFC connections to those programs have to be defined. This isn't required in part programs that solely need to outline the RFC connection to the WPS for this purpose. The definitions of RFC connections are client unbiased and are held in desk RFCDES. The identify of the RFC connection must match exactly that of the logical names of the part systems. The connection sort is “3,” which signifies that it is an R/three connection (Foundation).Additionally, SAP recommends utilizing the load distribution feature for these connections.

For the RFC communication to operate correctly, it is required to outline a CPI-C consumer for each of the part programs with the SAP_ALL authorization profile. This person ought to be defined at the beginning of the customization process.

ALE Distribution Mannequin

The ALE distribution mannequin is first outlined in the WPS and later distributed to every of the component systems. This configuration is a three step course of that may be performed using transaction BD64.

1. First, while in change mode, choose possibility Create mannequin view for creating a model new ALE distribution model. This mannequin shall be recognized by a
2. The logical system of the WPS is defined because the sender and the logical name of the element system is the receiver.
3. The subsequent step is to generate the associate profile, which is required for the ALE distribution. This is accomplished by choosing Atmosphere/Generate associate profiles from the menu.
4. Next, the mannequin should be distributed to the element systems. This is carried out by deciding on Edit/Model view; then the ALE distribution mannequin and all the logical names of the element methods are selected. The companion profiles must also be generated within the element systems.

CUA Configuration

The CUA utility is activated within the WPS utilizing transaction SCUA. For each of the weather of the consumer master knowledge, you can define whether or not they are going to be maintained globally from the WPS or domestically from the part system. This is accomplished utilizing transaction SCUM.


Integrating Current Systems

There are two ways of implementing CUA with present methods:

1. Ranging from scratch, creating all person grasp records
2. Using the existing user grasp data that might be migrated to the CUA atmosphere

Within the first case, the consistency for the information to be distributed is guaranteed. Within the second case, wherein CUA is implemented when there are already person master knowledge records, there must be a migration course of to reuse this data, which will need to be modified and validated within the Workplace server. Likewise, both the easy and composite roles in addition to the user assignments to those roles or exercise groups should be known to the WPS. The assignment of authorizations to easy roles must still be maintained in local programs (element methods).

Migration Software

The migration of user master information from the prevailing part techniques to the Workplace server will be carried out using the transaction SCUG (option Switch users). The migration is finished only once for every of the part systems. After knowledge is transferred (migrated), the person grasp data can only be maintained throughout the WPS based on the sphere attributes which have been outlined . A consumer account (consumer grasp record) ought to have the final and first identify in all of the element programs utilizing CUA the place the identical user should be defined. When transferring users using the Migration Software, three circumstances are possible:

1. The consumer account in the component system does not exist within the Office server. On this case, the migration can happen without problems.
2. The user account already exists in the WPS with the identical first and last name. On this case, the account may additionally be transferred with out problems.
3. The person account within the element system exists in the WPS but has a totally different first or last name. On this case, earlier than transferring the data, the ambiguity ought to be resolved. If the name on the WPS is the proper one, the information might be migrated. On the contrary, the username in the WPS should be modified before using the common user upkeep
4. transaction SU01.

Once the CUA utility is activated, the appearance of the SU01 transaction modifications slightly. Within the WPS there could be an additional tab Systems. This tab will contain the logical techniques the place the person data needs to be distributed. The person is just available in those systems. Within the tabs Roles and Profiles, there is also a Systems column. On this means, the project of users to simple roles, composite roles, and profiles could be defined individually for each of the element systems.When the possibility Save is chosen, the info is distributed.

The creation and upkeep of simple and composite roles takes place within the part systems. For assigning these roles or authorizations which would possibly be solely recognized within the element techniques, the choice Text comparability for little one techniques should be selected in the folders for profiles and activity groups. The names of the roles and authorization profiles are replicated to the WPS. From that moment, these names will be available in the WPS (use the help operate F4). Because this information might be modified at any time and in any of the component programs, the replication operation should be repeated regularly.

CUA Log System

Every change in the person data is distributed asynchronously to the element system. These systems reply to every change by sending a message to the WPS. This message is often a profitable, warning, or error situation. That is displayed utilizing transaction SCUL.

Managing Roles within the Office

Within the mySAP methods, actual application components are offered by technique of Business Scenarios. These eventualities are provided on a role basis in order that clients can select SAP functionality for the roles they need. Customers can have several roles within Business Eventualities or can take part in numerous ones. For occasion, a person might be knowledgeable purchaser, however at the same time needs the Worker Self Service functionality or access to components of the financial accounting. This might be a actual-life instance of why the concept of roles is so important and fundamental inside mySAP. The performance of the roles is handled in the Workplace. The mySAP Workplace consists of a large set of predefined roles prepared for use or for copying and adapting to specific firm needs.

From a logical standpoint, a task is the outline of a job place, function, or responsibility inside a company organization. Your complete working setting of the mySAP technique is targeted on the position concept. That's, every person defined within the mySAP Office will must have one or a quantity of corresponding roles. From a technical standpoint, a task is made up of a collection of transactions, Internet hyperlinks, stories, MiniApps, non-SAP purposes, and so on. Moreover, a task is associated with the required authorizations to have the option to begin and execute the functionality related to the role. Principally, roles define which transactions, which info, and what companies are available for the users of the Workplace.



Defining Roles

The primary query that must be answered within a Office atmosphere configured with several component techniques is,The place are roles managed? Depending on the function kind, roles are outlined and managed in the part systems or in the WPS.

1. The first step for defining a role is to outline to which techniques the user having such a job could have access.
2. Subsequent, the roles (menus) are created, and the authorizations and profiles are generated for every role defined.
3. As quickly as roles are generated, they should be assigned to the corresponding users. How and when this task takes place relies on whether or not the CUA is used or not. If the CUA is not getting used, the roles should be assigned to the users, and then the administrator should perform a consumer comparison for transferring the authorization values to the consumer grasp records. If the CUA is used, the function project is completed later within the WPS.
4. Subsequent, the function definitions and the person assignments are transferred, in the case of not utilizing the CUA. For configuring the Workplace, the customers and roles have to be available to the WPS.
5. The composite roles are defined inside the WPS. If the CUA is enabled, the administrator should assign the customers to the techniques to which they should have access.
6. The final step is to assign composite roles to the WPS users.

Defining Easy Roles

Simple roles are first created and maintained within the element programs, to be later transferred to the WPS. Roles could be created from scratch. However, SAP provides a large assortment of ordinary roles that might be imported and later copied and used in order that prospects can modify their needs without starting from scratch. There's a standard report, RSUSR070, which supplies an inventory of consumer roles that are supplied by SAP. You too can use the SUIM (user and authorization data system) to generate an outline of available roles.

Menu Design

The role administration is performed utilizing the traditional transaction for the Profile Generator: PFCG. You too can entry the utility by selecting Tools/Administration/ Person Maintenance/Roles. The consumer menu options (LaunchPad) may be adapted to consumer necessities by including or deleting transactions and folders, together with studies, Internet hyperlinks, files, and MiniApps. When a report is included inside a job, the Profile Generator creates a consumer-outlined transaction code so that the user can begin the report. Generating Authorization Profiles Roles are maintained using the Profile Generator transaction PFCG, which robotically generates the authorizations comparable to the transactions which can be previously chosen using a menu tree for the consumer role. There is, nonetheless, some manual maintenance for these authorizations as a consequence of there are values that should be outlined by the client for every case: as an example, the organization structure allowed, activities, and so on.

When maintaining and generating profiles to be assigned to roles, the display exhibits a yellow light right by the object if the authorization objects will not be utterly maintained (don't have values assigned). When all values are assigned, the light becomes green. Once all values are adjusted for the authorization objects in accordance with the consumer necessities (the authorization project), the profile will be generated just by clicking on the Generate button.

Related posts

What is SAP and Why do we are in need of It
What is SAP Full form and its definition part one

SAP authorization and client administration in mysap.com

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

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

EDI ALE IDOC tools for displaying information part two

In the previous post we discussed about IDOC tools for displyaing information required for SAP user and this post is in continuation with that.

The data records portion of the IDoc displays the data records sequentially. We can view detailed information for a record by selecting the record on the tree display. The field contents then appear in the Content of Selected Segment window.

For a more comprehensive display of the segment, click the page icon to the left of the segment name in the tree display. This view's major advantage is that it gives access to value help for any fields via function key F4. This enables you, for instance, to display a list of possible values for a qualifier field.


If a data element is blank in the IDoc, it does not show up on the screen.

The status records portion of the IDoc displays the status records sequentially. An arrow icon in front of a status record indicates that a message is available in the status record. You can double−click the message to view its long text. Double−clicking the record displays additional details of the status record, such as the date and time .

If a status record contains application error information, you can also see a segment number and a field that is in error. This information is displayed only if the application that processes the IDoc has logged this information.


IDoc List:

The Transaction code for idoc list is WE05 and the menu path is From the Area menu of EDI, choose IDoc, IDoc List.

The IDoc List program is used ALE/EDI interface tool for viewing the status of an ALE/EDI process. This program generates a list of IDocs that match your selection criteria. The selection parameters of this program allow you to restrict the number of IDocs that are selected.

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

Look for the next post for the continuation of IDOC topics.

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

SAP ALE IDOC'S displaying information

The IDoc Display tool is one of the most commonly used tools for viewing the status of an ALE/EDI process. This tool generates a list of IDocs that match your selection criteria. As mentioned earlier, after an IDoc is created in the system, all the status information at various milestones is recorded in the IDoc's status records.

This tool's selection parameters allows us to restrict the number of IDocs that are selected.

The output is a list of IDocs sorted by date and time.We can double−click any line to display the specific IDoc. If the selection results in exactly one IDoc, the system displays the IDoc directly,it without going through the intermediate step of listing the IDoc.

The IDoc Display screen lists the IDoc components, including the control record, data ecords, and status records.

The Control Record screen displays commonly used information about a control record. We can obtain additional details such as technical details, EDI details, and address informationby selecting the appropriate tab.

The previous post deals with SAP INBOX work items and processing log.

SAP Inbox Work Items and Process Log

we have been discussing about SAP inbox in the previous posts and here we are going to deal with Executing Additional Operations on a Work Item.

Forwarding: You can forward a work item to another person to work on it, as long as that person is one of the possible agents.
Reserving: By reserving a work item, you can take ownership of the work item task without executing it. This step makes the work item disappear from other Inboxes.

Replacing: If you start working on a work item that was sent to multiple agents, it disappears from other Inboxes. If, however, you decide that the work item is not for you, you can replace it in the pool. It will then be available to you, as well as the other original recipients.

Setting an item to done: Any work item that does not have a terminating event can be completed by setting it to done. This step removes the work item from your Inbox.

Resubmitting: If a work item does not require your immediate attention, you can make it disappear temporarily. It will reappear in your Inbox upon expiration of the specified time. For example, if you receive a work item and decide that you will work on it two days later, you can use the Resubmit option to make the work item disappear from your Inbox for two days.
Displaying the Processing Log for the Output Type

The processing log is maintained in the Message control component to provide details of an output type's processing. This log is available only for applications that use Message control to send an output. It is helpful for end users who create application documents and want to know the status of the output.

For example, an accounts receivable clerk who created a billing document for a vendor might want to find out whether a message was successfully processed.

Steps to view and interpret the output log:

1.Go to the output control screen of the application document. You can usually reach this screen by choosing the menu options Header, Messages or Header, Output. The output list in Figure shows the various output types for this document. The list is sorted by time, so if you have multiple output types of the same kind, the latest output type is at the top.

2.Look at the Status column (column 1) for your output type:

Yellow. The processing has not started yet. The timing of the output was not set for immediate processing; it's waiting for the next run of the RSNAST00 program. If you want to start the processing immediately, you click the Further Data button, set the timing in the Send Time field to 4, and save your document. That starts the processing.

Green: The output was successfully processed. You can find additional details, such as the IDoc number generated for the output, by selecting your output type and then choosing Goto, Processing Log from the menu .

Red: Errors occurred in processing the output type. You can find additional details about the errors by selecting the output type in error and then choosing Goto, Processing Log from the menu. The log will display the error message. To view the long text for the message, click the Message Long Text icon .

he previous post of the blog deals with SAP INBOX and monitoring errors .
Also know about SAP INBOX work item processing here.

SAP INBOX Work Item Processing

SAP Inbox work list is the previous post we had discussed and here we are going to learn about how to process a work item in SAP Inbox.

Processing a Work Item from SAP Inbox:

On the worklist window, you can double−click the work item, or you can click the Execute button on the work item detail screen. When you click the Execute button, you are automatically established as the owner of this work item, and it disappears from the Inbox of other selected agents.

Executing a work item starts the task behind it. You do not have to know the transaction or the underlying data. Executing a task automatically takes you to a screen with all the information filled in. From this screen you execute the task steps. This screen is different for every task, but the concept behind executing any work item is the same.

The work item in the below represents an application error in an incoming invoice. From this screen, which displays the IDoc's last status record, you can analyze the error. After you fix the error, you restart the failed process by clicking the Process button.

If a work item is sent to multiple users, each user can see an entry in his or her Inbox. As soon as
one user reserves or executes the work item, its status is changed to reserved, and it disappears
from the other Inboxes.

If the user who first looks at the work item decides not to work on it, he or she can replace the work item in the pool by executing the Replace function from the Inbox. This step returns the work item to the original Inboxes.

Marking a SAP INBOX Work Item as Complete:

Work items are automatically removed from the Inbox when the task they represent is completed. They can be classified into two categories.

1. Work items requiring a terminating event ·
2. Work items not requiring a terminating event ·

Terminating events are raised from within applications. The workflow management system then automatically removes the work item from your Inbox. For example, work items for application errors associated with an IDoc are completed by the terminating event ErrorProcessCompleted.

After you fix the error and restart theprocess and the document posts successfully, the work item automatically disappears. The advantage of this method is that the task can be executed outside the workflow system and the work item disappears from the Inbox. However, such work items cannot be deleted from the Inbox unless a terminating event is raised.

To find out whether a work item requires a terminating event, display the work item details by selecting the work item and clicking on the Display icon. On the resulting screen, select Goto, Technical Work Item Display.

This screen has a check box, labeled "Processing End by User Confirmation," to indicate whether the work item requires a terminating event. This box will be empty if the work item requires a terminating event.

Work items of the second type are completed when a user's explicit input indicates that the task is complete. SAP uses this approach for tasks for which it cannot determine the completion. For example, if the task is to write a letter, the system cannot know when you are done.

In the SAP ALE/EDI process, tasks that are for information only for example, technical errors in the IDoc interfaceuse this approach. The system displays the error. Upon exiting, the system asks whether you want to complete the task. If you click the Complete Processing of Step button, the work item is considered complete and disappears from the Inbox.

The system cannot validate what you have done to complete the task logically outside workflow. If you click Cancel, the work item stays in your Inbox, and you can reprocess the work item later.

he previous post of the blog deals with SAP INBOX Work list.
and you can go through entire EDI Course here.

SAP Inbox Work List

Viewing a Worklist

A work list is a list of work items sent to your SAP Inbox. Click the Workflow node to see a list of all the work items for which you have been selected as the responsible person. The default list has nine columns .

1. Column 1. Displays an icon indicating that the work item is executable.
2. Column 2. Gives a short description of the work item.
3. Column 3. Displays an icon indicating the work item's status.
4. Column 4. Displays the work item's creation date.
5. Column 5. Displays the work item's creation time.
6. Column 6. Indicates the work item's priority.
7. Column 7. Indicates whether an attachment is associated with this work item. An attachment can be a file, a note, a business document, or any other object the system supports.
8. Column 8. Indicates that the user must confirm the end of processing.
9. Column 9. Indicates whether the work item is overdue.

The work list includes a short description of the work item. To see additional details (such as status, long text, terminating event, selected agents, IDoc number), double−click a work item's Description entry or select the work item and click the Display icon.


The Description box on the Basic Data tab is usually blank. As part of workflow customizing, you can change the text that appears in this box. From the menu options on this screen, you can obtain additional information about a work item.

For example, to find out who else received this work item, choose Goto, Agent, Selected Agents. You can also find a work item's technical data, such as the task number. Another important piece of information is the IDoc number, which you find by clicking the Available Objects tab and choosing the Process Objects folder.

he previous post of the blog deals with SAP INBOX and monitoring errors.
and you can go through entire EDI Course here.

EDI SAP Inbox and Monitoring Errors

Previously we have discussed regarding EDI Inbound process testing. Now we are going to deal with Errors monitoring via EDI SAP inbox.

Workflow is useful for detecting errors that are infrequent, unpredictable in timing, and meant for a specific group of people.

For example, assume that you are in charge of handling errors with purchase orders going out to your vendors via EDI. Several purchasing clerks can create purchase orders in the system. You could try to stay up−to−date with the problems by displaying a list of purchase orders created in the system every hour, looking for purchase orders that go via EDI and then checking the status of each output to make sure that the EDI part is correct.

You could devote your entire day to monitoring the system manually and not find a problem, or you could be busy doing something else and end up being accountable for an unresolved error.

The transaction codes are

Transaction (prior to version 4.6): SO01
Transaction (from version 4.6): SBWP
Path: From SAP Easy Access menu, click on Business Workplace icon

The SAP Inbox is an interface to view and process work items and SAP office documents . It is similar to the inbox of any e−mail system and contains separate folders for the office documents and work items. The office documents are e−mail documents, and the work items are workflow items.

The number next to each folder indicates the number of items in the folder. Workflow items are accessible in any of four folders within the overall Workflow folder. Each folder displays the work items in a different order according to task, content, content type, or sort key.

The work item highlighted in the worklist is displayed in the preview window below the worklist. You can customize this preview window through the use of a user exit.

Understanding Work Items

A work item represents an instance of a task that needs to be executed. For example, a workflow task (Orders_Error) handles application errors in the orders IDoc. When a sales order IDoc has application errors in posting, a work item representing this task is instantiated. A work item has brief text describing its purpose .

A work item is executed from the Inbox to carry out the task, and can have more than one status governing the operations allowed on it.

As part of the ALE/EDI interface, items that can appear in the SAP Inbox. Because work items are intelligently routed to the person responsible for them, the work item's type determines who is notified. You can expect to see work items for the following items.

1. Errors in the outbound ALE/EDI interface.
2. Errors in the inbound ALE/EDI interface.
3. Syntax errors in an IDoc for the outbound process.
4. Syntax errors in an IDoc for the inbound process.
5. Application errors in posting an IDoc on the inbound process.
6. Errors reported by the EDI subsystem.
7. Technical errors in the EDI interface with reading and deleting IDoc files for the inbound process.
8. A predefined threshold state exceeded by the number of IDocs. For example, someone is notified
9. when at least 10 sales order IDocs are not posted because of application errors.
10. Inbound EDI processes routed via workflow. For example, someone needs to review an order change IDoc before it is posted.

Successful posting of an application document. For example, you want to view invoices whenever
they are successfully posted in the system via EDI.

The previous post of the blog deals with EDI Testing outbound process
and you can go through entire EDI Course here.

SAP ABAP EDI Inbound ProcessTesting

To check weather the electronic data interface of SAP is working properly or not we do have different test to do.

We do test various components of SAP ABAP EDI Inbound process and they are

1. The inbound triggering process ·
2. The successful creation of IDocs in the database ·
3. The posting of the application document.

A multitude of errors can be related to data errors. Detailed information about a specific error is also logged in the status record, and an error workflow is started to notify the person responsible for handling the error. If your posting program uses the Call transaction to post the document, you can step through every screen to determine the exact location of the error.

This can be shown diagrammatically as shown below.



How do we Verify the Inbound Triggering Process ?

This step tests the connectivity between the subsystem and the SAP system.This test requires the process to begin at the OS layer using an IDoc file.

The results of executing the startrfc command are displayed at the command line where you started the program. The errors are usually from message class E0. If you see a message with E0, you can use transaction SE91 to look up the details of the message. If the error message is unclear, you can turn on the trace when executing startrfc to view detailed information.

The problems in this test could be

1.Permission problems in executing the startrfc command. You must have proper authorization to execute operating system commands.

2· Problems with input parameters. The parameters must be specified according to the syntax. It may be the user ID and passwords have problems. You can use your logon ID to test the process.

3·Problems with the gateway services. You can use transaction SMGW to check the status of your gateway services. Gateway services are used for every CPI−C communication, and RFC is implemented using CPI−C protocols. Check with your Basis staff for appropriate gateway service
values.

4·Problems accessing the inbound file. The file system, if NFS mounted, might not be available, or SAP does not have authorization to read the file.

5· If this step is successful, an IDoc should be created in the SAP database .and don't bother errors in the IDoc at this stage. The scope of this test is limited to ensuring that the triggering process works.

How to Verify the Creation of Successful IDocs ?

In this step, we use the information in the IDoc's control record to verify that a partner profile is found and that the IDoc is created without any structural errors. This step is useful for custom IDocs when you want to make sure that the incoming IDocs are structurally correct.

Here we have to start the inbound process with one of the utilities and shall not start from a file.

The results are logged in the IDoc's status records. You can display the status records by using the IDoc display utilities. If an error occurs, the IDoc gets a status code of 56 (IDoc with Errors Added), and an error workflow is started.

The person notified in this case depends on whether a partner profile could be read. If a partner profile was found, workflow is sent to the person specified in the partner profile. If a partner profile entry could not be read, the message is sent to the IDoc administrator.

Common problems in this step are related to data in the control record and to syntax errors in the IDoc. The parameters in the control record must match the key of the partner profile record for that inbound message.

The status records should give you the specific details. If this step is successful, you will see an IDoc that has a status code of 64 (IDoc Ready to Be Passed to Application).

How to Verify the Posting of Application Documents?

The transaction code is BD87.

The logic for posting an application document is coded in inbound function modules. Verifying the logic of the inbound function module is the most important step for custom function modules. You verify not only that the posting function module is working correctly, but also that the logic and interface of the function module are correct. If problems exist, you might also want to debug the process one step at a time.

The IDoc created in the "Verifying the Creation of Successful IDocs" section is used to test this process. To start, execute program RBDAPP01 via SE38, or execute BD87. Then, enter your IDoc number and start the process. The selection screen for the RBDAPP01 program appears in Figure below.
Errors in this step are mainly related to data errors and are logged in the status records of the IDoc. You can display the status records by using the IDoc display utilities. The IDoc gets a status code of 51 (IDoc with Errors Added).

The common problems in this step are either data related or in the application configuration, so you must make sure that the data values are correct in the data record fields. Check your program logic for any errors.

If this step is successful, an application document is created, and the IDoc gets a status code of 53 (Application Document Posted). The document number is logged in the status record. For example, if an incoming IDoc creates a sales order number 10000, this number appears in the last status record.

The previous post deals with SAP ABAP EDI Inbound process utilities.

The previous post of the blog deals with EDI Testing outbound process.

SAP EDI Inbound Process Utilities

SAP EDI inbound process do have different utilities to test inbound process.They are

1. Start the Inbound Process by Copying an Outbound IDoc as Inbound.
2. Start the Inbound Process from an Inbound Text File.
3. Start the Inbound Process with the Inbound Test Tool.

Let us know about each utilities in detail.

1.Start the Inbound Process by Copying an Outbound IDoc as Inbound is also called the turnaround utility, uses that principle to copy an outbound IDoc file as an inbound IDoc file and start the inbound process. This utility is useful if you already have an outbound process that is generating an IDoc type you want to use for your inbound testing.

we start this utility via transaction WE12. The selection parameters allow you to change the sender and receiver fields, as well as the message type and this utility does not allow you to change the actual data contents. We have to make sure that data in the outbound IDoc can be used for an inbound process. After entering the parameters, click the Execute button. The system displays the following message.

The transaction code to start this utility is WE12 and the menu path to access it is From the Area menu of EDI, choose Test, Inbound procg of modified outb.file.

2. Start the Inbound Process from an Inbound Text File

The transaction code is WE16 and menu path is From the Area menu of EDI, choose Test, Inbound procg of.orig.inb.file.

We can use this utility to start the inbound process from an inbound file, but first, we have to build an inbound file.

Different ways to start in bound process are

1.Copy an existing inbound IDoc in the system, and save the IDoc to a file via transaction WE19, by selecting an existing IDoc number and clicking the Create icon. On the next screen, you can change the values. Then, click the Inbound File button, enter the file name, and deselect the Start IDoc Inbound Processing of File Immediately flag. Click the Continue button, and an IDoc file is created .

2.Copy an outbound file and modify it to look like an inbound file. Alternatively, if you have an outbound file, you can set a breakpoint while executing the turnaround utility. Set the breakpoint where it has copied an outbound file, has modified it to look like an inbound file, and is ready to start the inbound process. At that point, you can end the session. Now you have an IDoc file you can use for your inbound process.

After creating the IDoc file, you can start inbound processing using utility 2. The selection parameters of this program allow you to specify the file name for the inbound IDoc file and then click the Execute button to start the inbound processing.


The previous post of the blog deals with EDI Testing outbound process.

ABAP DICTIONARY OVER VIEW

TABLE TYPES IN ABAP

CHANGES TO DATA BASE TABLES

SAP ABAP EDI Testing Outbound Process part two

We have discussed about SAP ABAP EDI outbound process testing part one and this discussion is in continuation with that.

How do we verify that Idoc is generated or not ?

If we extended the IDoc selection program via user exits, modified it, or created a new one, this step allows you to debug our program logic.Transaction code for testing IDOC generation is WE15 and the menu path is From the Area menu of EDI, choose Test, Outbound from MC.

We can also test this step by executing the RSNAST00 program via transaction SE38 or by directly executing transaction WE15 and it step processes the NAST entries we have created in the preceding step and calls the selection program for that message.For example, IDOC_OUTPUT_ORDERS will be called for message type ORDERS.

After a NAST record has been processed successfully, the record can be resent either by selecting the Send Again check box without creating a new document or by going into the application document again.


If an error occurs during the execution of RSNAST00, it creates an output log that is displayed on the screen and we can also find extended help on each record of the log by clicking the Documentation button.Another possibility is that syntax errors have been found in the IDoc. The IDoc will be in status 26 (Error during Syntax Check of IDoc). We use transaction WE02 to display IDocs in the system. The status record in the IDoc tells you whether syntax errors were generated for the IDoc.

If you are testing a standard SAP−supplied program, errors at this stage are rarely due to program logic. The possible causes of the errors are

1.The partner profile has an incorrect process code. You can perform a syntax check on the partner profile.

2· The application document has been deleted. Display the application document to confirm that the document exists.

3·The application document contains an inconsistency. For example, partner functions might not have been defined.

4· The program logic has errors. If you have developed your own selection program or extended the standard program via user exits, check the program logic for errors.

If this step works correctly, a success message will appear in the output log window and we can then use transaction WE02 to display the IDoc. It must be in status 30 (IDoc Ready for Dispatch).

How to verify Connection between the SAP System and the Subsystem ?

The connection is responsible for the greatest number of problems because it crosses the boundary from SAP to the OS layer. If we successfully tested the components, we won't experience any problems at this juncture.

The transaction code for testing the connnection is WE14 and the menu path: is From the Area menu of EDI, choose Test, Outbound Processing from IDoc.


Learn about SAP ABAP EDI Complete HERE by following the link.

TYPES OF VIEWS IN ABAP

DATA BASE DIALOG

ABAP DATA BASE UPDATE

What is Idoc-overview

An IDoc is a container that can be used to exchange data between any two processes. The document represented in an IDoc is independent of the complex structure used in SAP to store application data. This feature enables SAP to rearrange its internal structure without affecting the existing interfaces.

An IDoc represents an IDoc type and IDoc data, depending on the context in which the word IDoc is used. An IDoc type defines the structure and format of the data being exchanged. For example, the IDoc type INVOIC01 defines the format of an invoice document. IDoc data can be seen as an instance of an IDoc type.

IDoc Types

IDocs types are based on EDI standards (ANSI X12 and EDIFACT). They are closer to the EDIFACT standards than to ANSI X12. The size and format of data elements in an IDoc type are derived from these standards wherever applicable. The IDoc format is compatible with most EDI standards.

An IDoc structure consists of several segments, and segments consist of several data fields. The IDoc structure defines the syntax of the data by specifying a list of permitted segments, the arrangement of the segments, and optional versus mandatory segments. Segments define a set of fields and their formats.

An IDoc is an instance of an IDoc type. Each IDoc is assigned a unique number for tracking and future reference. An IDoc serves as a focal object for tracking the state of the process that generated it. An IDoc consists of the following three types of records.

Parts of Idoc

1. One control record
2. One or many data records
3. One or many status records Control record. There is only one control record per IDoc. The control record contains all the control information about an IDoc, including the IDoc number, sender and receiver information, and other control information such as the message type it represents and IDoc type. The structure of the control record is the same for all IDocs and is defined by SAP. The field values, of course, can be different.
4. Data record. An IDoc can contain multiple data records, as defined by the IDoc structure. Segments translate into data records. Data records store application data such as purchase order header information, purchase order details lines, and other relevant information.
5. Status record. Multiple status records are usually attached to an IDoc. Status records are attached to an IDoc throughout the process as the IDoc achieves different milestones. A status code, date, and time are assigned at every milestone.

In the outbound process, after the IDoc is passed from SAP to the subsystem, the status records are generated by the subsystem and passed back to SAP. For the inbound process, SAP generates the status records because after an IDoc is generated, it stays in the system. Status records help you determine the status of the process and whether an IDoc is in error.

Multiple Messages per IDoc Type

A message represents a specific type of document that is transmitted between two partners. Orders, order responses, order acknowledgments, invoices, and shipment notices are examples of messages. An IDoc type in SAP can be used to represent several messages or business documents. Of course, the messages must be logically related.

For example, in the figure , an IDoc type represents all possible information about an employee. This IDoc type is being used to send two separate messages to two separate applications. One message is the Employee Salary Information; the other is the Employee Security Information. The difference between the two messages is the set of segments used.


SAP uses a single IDoc type for several logically related messages. For example, the Orders IDoc type (ORDERS02) is used for several messages, such as Order (ORDERS), Order Response (ORDRSP), and Order Change (ORDCHG).

See complete course about ALE IDOC'S HERE.

Related Posts about EDI:

EDI outbound process
EDI Process components AND part two Business Processing using EDI