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

ERP Business Process Cycle SAP ABAPer Need to Know This

ERP Need to implement a business process and SAP uses a effective step by step method to do this in a systematic way with regular check points every where so that you can monitor the business process at all stages and control it.Every SAP ABAP programmer need to know this process to give a effective way of writing and modifying the code.

Effective sales order processing connects all exercise to buyer demand in a sequence of built-in processes. The application component Sales and Distribution makes this gross sales order processing possible. The steps in a sales process are then reproduced by digital documents which would possibly be linked to each other.

The client order management process begins with establishing and maintaining buyer relationships, and ends with invoicing for supply of goods or service offered to the customer. Posting the customer incoming funds is a part of the applying component Financial Accounting. The Buyer Order Management cycle can begin with Pre-Gross sales Activities. For example, in response to a buyer inquiry , you create and send a quotation.

As part of gross sales order processing, you create a sales document. Throughout procurement, the system determines the supplier of the products, based mostly on knowledge that you have stored in the system.As part of delivery processing, you organize and perform the delivery of goods.Within the billing course of, you create the invoice and switch all the required information into Accounting. As a part of dealing with payments, you check open items and put up incoming payments.Specific marketing measures, for instance, direct mailing campaigns, internet campaigns, trade honest gross sales actions or telephone campaigns, can trigger gross sales processes.

Doable sequences of such campaigns could be a non-binding buyer inquiry or a request for a quotation. Inquiries and quotations assist you to to find out essential sales-related information and may be saved as documents. If the shopper then locations an order, you'll be able to seek advice from this data.Use this pre-gross sales info to plan and consider your marketing and gross sales methods and as a basis for establishing long run business relationships with your clients, for instance by

Monitoring misplaced sales

Recording pre-sales knowledge to assist negotiate giant contracts.Promoting goods and providers to giant organizations that require documentation of your complete process.A gross sales order is an electronic doc that data your buyer's request for items or services. The sales order contains all data to course of the customer's request throughout gross sales order processing.The sales component thus mechanically proposes knowledge from grasp data and management tables that you previously stored. Consequently, potential input errors occuring during sales order processing and getting into of redundant data is avoided.

You can enter a gross sales order with many items on a single screen. Gross sales orders can be created via the internet or via messages received from business partners.A sales doc is created in a gross sales area.A gross sales order can seek recommendation from a enterprise transaction that already exists within the system. For instance, one or more inquiries and quotations can be reference documents. In this case, the SAP System copies the related information to the gross sales order.A citation can even result in a quantity of sales orders. This lets you group all the quotations for one customer.A gross sales doc is grouped into three ranges: header, merchandise and schedule line. Information is distributed on these ranges as follows:


Sales document header

The info in the document header is valid for your entire document. This contains, for instance, buyer-associated data.

Gross sales doc gadgets

Every item in the gross sales document contains its own data. This consists of, for example, knowledge about the material and portions ordered.Every gross sales document can have a number of objects, whereas particular person objects could be managed differently.Examples embrace material merchandise, service merchandise, free-of-charge item or text item.

Item schedule lines

Schedule strains comprise delivery portions and delivery dates. They belong uniquely to an item.Every merchandise that has a subsequent outbound supply within the gross sales and distribution process will must have at the least a schedule line. The merchandise can have several schedule strains, for example when the quantity ordered is to be delivered in several partial deliveries at completely different times. To course of the sales documents effectively, the info might be displayed and processed in different views. The views are grouped into overview, header and item screens. A brand new sales document is entered on an outline screen.

The finest way during which a material is obtained for a sales order can depend on the kind of material and on the sales transaction. The procurement can, for example:

1. Be from accessible stock
2. Be assured by replenishment
3. Trigger make-to-order production

Initiate the outbound supply utilizing external suppliers (third-celebration enterprise transaction) . Organize the outbound delivery from another warehouse. On the Gross sales and Distribution tab web page in the materials grasp you can: enter in Gen./Plant within the availability verify discipline, which and/or what sort of availability examine needs to be carried out for this material throughout order processing.

There are also varied tables in Customizing, on which the provision check can be dependent. From the supply control display screen, you possibly can access the Obtainable to Promise (ATP) quantities, the scope of check for determining available amount, and the other vegetation which will have the material available.

Every gross sales and distribution doc contains information required for the document and for additional processing.The system determines which fields are displayed within the incompletion log when the consumer doesn't fill them during sales order processing.The incompletion log shall be displayed a) routinely once you save your entries. You can even name it by selecting Edit -> Incompletion log.

In Customizing, you may resolve which fields needs to be part of the incompletion log. The incompletion log functions can be found within the sales order and within the delivery. Internet Sales R/3 Edition and CRM Internet Sales are SAP’s Web Shop options for selling products on the Internet.

Benefits of the 2 solutions:

Internet Sales R/three Edition:

1. The shopper works with the R/3 System and needs to establish a further distribution channel on the Internet. This channel could be set up very quickly with the Internet Sales R/three Edition.

2. The only extra software program required is a J2EE-Server.

CRM Web Sales

1. Integral component of the SAP CRM system
2. Enhanced functionality as compared with the Internet Sales R/three Version (e.g. Marketing integration)
3. It is doable to run the CRM with no SAP R/three within the again end.

Delivery processing in Sales and Distribution begins if you create the delivery document. The supply document controls, helps and displays quite a few sub processes for shipping processing
resembling

1.choosing and confirming (transfer requests),
2.Packing,
3.planning and monitoring of transport (shipment document) and
4.Posting the products difficulty (items difficulty paperwork).
5.Creating a supply document includes copying info from the gross sales order, such because the supplies and quantities, onto the delivery document.
6.Making a transfer order includes copying information from the supply doc to the transfer order for processing inside the warehouse. The transfer order is important for controlling the movement of items within your warehouse. The transfer order relies on a simple principle: the place you take items from and to, inside your warehouse. There's a supply location and a vacation spot location for every transfer order.
7.The posting of the products difficulty can bring a couple of change based on a quantity basis in addition to on a worth foundation in change stock. Adjustments based on a amount foundation are made on the relevant balance sheet accounts and inventory change accounts in financial accounting.You'll be able to create an outbound supply in a transport point for orders which are due for delivery. The SAP System copies the related data from the order to the outbound delivery.
8.You may create one or several outbound deliveries from the order. You can too combine objects from several orders into one outbound delivery. To combine them efficiently, the orders must all have the same characteristics which can be essential for the transport process, for example:

1. shipping point
2. Due date
3. Ship-to deal with

The SAP System can create deliveries both on-line or as a background job to be executed during
off-peak hours.A supply doc is grouped into two ranges: header and item. The data is distributed across these ranges as follows:

Delivery document header

The information for the doc header is valid for the complete document. This includes, for instance, knowledge for the ship-to get together and schedules for transport processing.

Supply doc merchandise

Each merchandise within the gross sales document incorporates its personal data. This includes data about the material, portions and weights in addition to stock information. Each gross sales doc can have several items.The items could be controlled differently. Examples embody material item, free-of-cost item or textual content item.

The supply doc does not contain schedule lines. Every schedule line within the sales document can become an item in the supply document.

To course of delivery documents efficiently, the information may be read and processed in numerous views. The views are grouped into overview, header and item screens.

You may control an item in an outbound supply so that selecting is required.

Picking is carried out by creating transfer requests with which you trigger and survey warehouse movements. The objects in the switch requests contain the materials and the quantites to be picked,which correspond to the supply quantities. On the identical time the delivery quantites are transferred into the outbound delivery as choosing quantities.

You'll find a way to print the decide list for use in the warehouse from the switch request.

Selecting confirmation can both be automated or can be carried out in a spearate processing step.

On the time of cargo, items which were not already packed in the supply, may be packed in delivery models utilizing transport materials. The functionality used here is basically the identical as for loading within the delivery.

Packed objects are assigned to the required means of transport (e.g., vehicles).

Delivery models from the supply are copied and might now not be changed.

Unlike packing within the delivery, packing in the cargo could be carried out for a number of deliveries.

If you submit goods issue, the system routinely:

1. Updates the quantities in inventory administration and supply necessities in supplies planning
2. Updates the value change within the balance sheet accounts for inventory accounting
3. Generates extra paperwork for accounting, for example, for controlling
4. Generates the billing due checklist
5. Updates the standing in all relevant gross sales documents

Once you create a billing document, knowledge is copied from the sales order and the supply document to the billing document. Supply items in addition to order items may be references for the billing document.

The billing document serves several necessary features:

1. It is the gross sales and distribution document that helps you to generate invoices.
2. The billing document serves as a knowledge supply for financial accounting (FI) to assist you to observe and process buyer payments.
3. When you create a billing document, the G/L accounts will normally be updated automatically.
4. During this process, the R/3 system carries out
5. a debit posting on the customer receivables account and
6. a credit score posting on the revenue account.

Related Posts:

sap abap list notifications and task programming with screen shots

SAP ABAP Sample Program for Order Cost Element Display

abap sales order management business process

Customer and Materiel Master Data in SAP ABAP for Sales Order

Customer master and materiel master data is needed to and it will be extracted in SAP ABAP reporting and it is very popularly used in Sales Order Report.Here we are going to discuss what are the contents of this data and how it is extracted as per requirement.Several sources of information will be copied into a gross sales order or into another gross sales and distribution document. Most of them are default values that you would have the ability to overwrite in the gross sales and distribution document, if necessary.

These sources of information include, for instance:

1. Customer master data
2. Materials master knowledge
3. Situation master information.
4. Output is data that's dispatched to the customer utilizing various media, equivalent to mail, EDI, or fax.

Examples embody the printout of a citation or an order confirmation, order confirmations utilizing EDI, or invoices by fax.

Control tables: You may create and preserve these tables in Customizing. The default values of several data may be controlled within the sales and distribution paperwork, relying on the table settings.

One sales doc can function a source of knowledge for another sales document. For instance, a quotation can serve as an information source for a gross sales order. The client master teams information into classes: normal data, gross sales area knowledge, and firm code data.

The final knowledge is related for sales and distribution and for accounting. It's stored centrally (client specific),with a view to avoid knowledge redundancy. It is valid for all organizational items within a client.



The gross sales space data is relevant for sales and distribution. It's legitimate for the respective sales space (gross salesborganization, distribution channel, division).The corporate code information is related for accounting. It is legitimate for the respective company code.

The customer master includes all data vital for processing orders, deliveries, invoices, and customer payments.The fabric grasp is grouped into a quantity of views: Primary data, sales and distribution information, purchasing knowledge, varied further knowledge for engineering accounting, costing, warehouse administration, and so on.

Primary data is relevant for all areas. It's valid for all organizational models inside a client. Sales: sales organization information is related for gross sales and distribution. It's legitimate for the respective sales organization and the distribution channel.

The sales: plant data is also related for sales and distribution. It is legitimate for the respective delivering plant.There's further information for several different areas. This is legitimate for numerous organizational units.You can use the shopper-materials info to file information for a mixture of certain clients and materials.

If a customer-materials info exists for a customer and a fabric, these default values are most properly-liked to the values from the client or the material grasp when processing a document .

You need to use the client-materials data report to take care of the next data:

Cross-reference from your customer's material number to your material quantity and the customer's materials description.

Specific delivery info for this customer and materials .

Output is data that's sent to the customer utilizing numerous media, comparable to mail, EDI, or fax. Examples embody: the printout of a citation or an order affirmation, order confirmations using EDI, or invoices by fax.

As with pricing, output determination takes place utilizing the condition technique. Output can be sent for numerous sales and distribution paperwork (order, delivery, billing doc) .In the output master knowledge, you define the transmission medium, the time, and the associate function for an output type.

Output varieties embody, for instance: citation, order affirmation, invoice. Accomplice features include, for instance: offered-to get together, ship-to get together, and bill-to party. Transmission media include, for example: printer, telex, fax, mail, EDI. Occasions at which output is shipped embody: immediately when saving, or by utilizing a normal program (RSNAST00) that's run regularly.

The layout of an output is defined by a form in SAPscript. The shape is assigned to an output type.The condition master knowledge consists of costs, surcharges and discounts, freights, and taxes. You may outline condition master data (condition records) to be dependent on various data. You can,for instance, preserve a fabric worth customer-particularly or outline a reduction to be depending on the client and the fabric pricing group.

In Customizing, you presumably can management the info on which costs, surcharges and reductions, freights or taxes may be dependent. Regularly occurring instances have already been set in the standard system.

Related Posts:

sap abap list notifications and task programming with screen shots

SAP ABAP Sample Program for Order Cost Element Display

abap sales order management business 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

ALE IDOC'S COMPLETE

Idoc which means intermediate document in transferring data across different systems of sap abap. The important topic of abap cross applications can be learned here completely in thirteen posts series as given below.


LESSON 1 DATA PORTS IN IDOC

LESSON 2 DEFINING PARTNER PROFILE FOR IDOC

LESSON 3 PARTNE RPROFILES AND PORTS IN IDOC

LESSON 4 CONVERTING DATA INTO IDOC SEGMENTS

LESSON 5 DEVELOPING OUTBOUND IDOC FUNCTION

LESSON 6 CREATION OF IDOC DATA

LESSON 7 IDOC DESIGN AND PROCESSING

LESSON 8 DISPATCHING IDOC

LESSON 9 ALE IDOC CHANGE POINTERS

LESSON 10 SENDING IDOC VIA STANDARD R3 SYSTEM

LESSON 11 IDOC OUTBOUND TEIGGER PART TWO

LESSON 12 IDOC OUTBOUND TRIGGER PART ONE

LESSON 13 ABAP IDOC INBOUND BASIC TOOLS


RELATED POST

ABAP 51 Days Complete Course
ABAP Dictionary
OOPS in ABAP
BDC
SAP Scripts
SAP Scripts Controls
SAP Smart Forms
Real Time ABAP Programming Reports
SAP Interview Questions
Syntax for ABAP Programming
ABAP Interface Programming
Financial and Controlling Sample Reports 

EDI
BAPI
BADI
ALE IDOC
SAP Work Flow
SAP Work Flow in Sales and Distribution
SAP Work Flow in Material Management
ERP Overview
My SAP
SAP CRM

ALE COMPLETE SERIES

Application Linking and Enabling is a important part of cross applications of SAP ABAP and here you can learn them in a systematic order in ten organized posts as given below.

SAP ABAP ALE PART 1

SAP ABAP ALE PART 2

SAP ABAP ALE PART 3

SAP ABAP ALE PART 4

SAP ABAP ALE PART 5

SAP ABAP ALE PART 6

SAP ABAP ALE PART 7

SAP ABAP ALE PART 8 ALE DISTRIBUTION SCENARIO

SAP ABAP ALE PART 9 ALE TRANSACTION CODES

SAP ABAP ALE PART 10 CREATION OF IDOC

ABAP TOPIC WISE COMPLETE COURSE

ABAP 51 Days Complete Course
ABAP Dictionary
OOPS in ABAP
BDC
SAP Scripts
SAP Scripts Controls
SAP Smart Forms
Real Time ABAP Programming Reports
SAP Interview Questions
Syntax for ABAP Programming
ABAP Interface Programming
Financial and Controlling Sample Reports 

EDI
BAPI
BADI
ALE IDOC
SAP Work Flow
SAP Work Flow in Sales and Distribution
SAP Work Flow in Material Management
ERP Overview
My SAP
SAP CRM

ALE 6

Filtering BAPI Parameters

The BAPI parameter filtering can also take into account a hierarchical dependency between BAPI table parameters.You must specify any hierarchical dependencies before you generate the BAPI-ALE interface of the BAPI.The specified hierarchy is evaluated when the interface is generated and incorporated in the interface coding.The BAPI-ALE interface must be regenerated following all subsequent changes made to the hierarchy.Once the generated IDoc type has been released, the specified hierarchy of the asynchronous BAPI cannot subsequently be changed because of compatibility problems.

Defining Hierarchies Between BAPI Parameters

If you are developing your own ALE business processes, you may have to define dependencies between BAPI table parameters with regard to filtering parameters for data selection.These dependencies are defined by the field references between the table parameters of BAPIs.You can filter parameters to determine the dataset and to define dependencies only for the distribution of master data via BAPIs that are called synchronously.

A BAPI for material master data contains the tables for plant data and associated storage data.The table containing plant data has a reference to the table containing storage data via the key field PLANTS.There is a hierarchical dependency between the plant and storage data.If plant 001 of a material is not to be replicated due to parameter filtering, then none of the storage data for plant 001 will be replicated.

You use BAPI parameter filtering to manage the size of the dataset in the BAPI interface.

Procedure

You can define these hierarchical dependencies in ALE Development under BAPI → Maintain hierarchy of table parameters.Enter the object type and the method of the BAPI. You can display existing BOR object types and their associated methods using the input help (F4).The following processing options are available under the menu Hierarchy :

• Create

• Change

• Display

• Delete

Create Hierarchy

This checks whether a hierarchy for the BAPI already exists. Then it checks whether an ALE IDoc interface has already been generated and whether the associated IDoc has been released.If the IDoc has already been released, then the generated interface has already been delivered to customers and no hierarchy can be created or changed for an existing BAPI because of compatibility problems.In this case you have to create a new BAPI. A corresponding error message is displayed. If the ALE interface already exists, but the IDoc has not yet been released, then the system will inform you that it needs to be regenerated.A hierarchy tree is displayed on the next screen. For details see Editing the Hierarchy Display further below.

Change Hierarchy

The same checks are made as when you create a hierarchy. On the next screen the same processing options are provided as when you create a hierarchy.

Display Hierarchy

The same checks are made as when you create a hierarchy. On the next screen you cannot make any changes to the hierarchy.

To display the field references between the tables, double-click on the parent table. The parent table is automatically copied to the next dialog box.Select one of the child tables from the input help. Select Field references to display the field references.

Delete Hierarchy

The same checks are made as when you create a hierarchy. Once you have confirmed you want to delete the BAPI hierarchy, it is deleted.

Editing the Hierarchy Display

The root node in the hierarchy display corresponds to the function module of the BAPI. The root node is used only for display and is not saved. Also, it cannot be changed. You can edit the hierarchy display as follows:

• Insert table parameters

• Delete table parameters

• Define field references between parent and child tables

• Save hierarchy Parent tables inserted directly under the root node that do not have child tables are not saved.

If only this type of table is created, there is no hierarchy and therefore a hierarchy cannot be saved.

Insert table parameters

Place the cursor on a hierarchy node and choose Edit → Insert table parameters. If you place the cursor on a root node, you can select a parent table of the highest level via the input help. If a table exists above the marked node, this is copied to the next dialog box and you can add a child table to this table.In principle a table can only exist once in the hierarchy. You can display the available tables via the input help.In the dialog box you can display the common fields of the parent and child of the table in which the field references can be defined by selecting Field references. You can mark the fields for which a field reference is to be defined.

If no field references between the two tables exist, an error message is displayed. Delete table parameters To delete a table, place the cursor on the relevant node of the hierarchy with the table names of the child table.

Confirm the deletion. All other child tables of the deleted table will also be deleted.

Define field references between parent and child tables

Place the cursor on the node of a child table and choose Edit → Table parameters → Change field references or select the pushbutton Field reference with the change icon. The next dialog box contains the parent parameters and provided that a reference exists, the child parameters too.

When you create table parameter, you can select the associated child table via the input help. You can display common fields by selecting Field references.Only field references are displayed that have the same names in the parent and child tables. You can define the references between the fields by marking the appropriate references. Field references already defined are marked already.

Save hierarchy

To save a hierarchy, choose Hierarchy → Save.

A transport request is generated to send the associated Customizing table to the correction and transport system.

The hierarchy is not saved if an error occurs when accessing the database. A corresponding error message is displayed.

Maintaining BAPI-ALE Interfaces

The standard R/3 System contains a large quantity of business objects and BAPIs. These include BAPI-ALE interfaces that are generated from BAPIs and enable asynchronous BAPI calls in ALE business processes.

You can develop your own BAPIs in the customer namespace and generate the associated BAPI-ALE interface. The following objects are generated for a BAPI: • Message type • IDoc type including segments

• Function module called in the outbound processing side. (It creates and sends the IDoc from the BAPI data).

• Function module that calls the BAPI with the IDoc data on the inbound processing side The difference to manually maintained message types is that the function module that processes the change pointers does not create an IDoc.

Instead it fills the corresponding BAPI structures, determines the receivers and calls the generated ALE function module. The message types, IDoc types and function modules that have been generated can also be used to distribute master data using the SMD tool.

Prerequisites

The essential prerequisite is that a BAPI exists:

• You have developed your own BAPI in the customer namespace. • You have modified a BAPI from the standard system.The BAPI-ALE interface is then created in the customer namespace for the new sub-type and a method assigned to it.

Regardless of whether SAP delivers a BAPI-ALE interface for a BAPI with the new Release, any interface you have generated will continue to function in the same as in the earlier Release.You can regenerate the old interface to adapt newly added parameters, provided that SAP has not delivered a new interface in the new Release.

If SAP delivers a BAPI-ALE interface for a BAPI for which you have already generated an interface, you should use the new interface and delete the interface you generated. You can still use the old interface in the earlier Release.

If you regenerate the old interface, some generated objects, such as segments of SAP objects could be overwritten, if the interface in your BAPI function module references BAPI structures but belongs to SAP.If you want to take into account hierarchical dependencies between BAPI table parameters, then another prerequisite is that you define the hierarchy before generating the BAPI-ALE interface

The specified hierarchy is evaluated when the interface is generated and incorporated in the interface coding.The BAPI-ALE interface must be regenerated following all subsequent changes made to the hierarchy.Once the generated IDoc type has been released, the specified hierarchy of the asynchronous BAPI cannot subsequently be changed because of compatibility problems.

RELATED LINKS

ALE IN BRIEF

MySAP CRM System architecture and design

MySAP CRM architecture and E procurement introduction

ALE 5

Reducing Interfaces Use

The purpose of BAPI and ALE integration is to be able to use ALE business process BAPIs as interfaces.BAPI reductions are particularly necessary in ALE business processes in which master data is replicated asynchronously:

• Part of the BAPI parameter is not required for the receiving system, even though it is declared when the BAPI is called
• Monitor data transferred into non-SAP systems (non R/3 and/or between business partners) (for example, hide fields).

• Certain data cannot be overwritten in the receiving system. BAPI reductions can however be used everywhere where asynchronous BAPI calls can be used. For asynchronous BAPI calls via the BAPI-ALE interface, only the parameters of the BAPI interface relevant for the receiver should be transferred.You can set up BAPI reductions in receiver-dependent filtering in the ALE distribution model. You can create templates for making reductions. Material master data is replicated from a reference system to a sales and distribution system.


As only some of the data on the material is required in the sales and distribution system, a reduction of the BAPI interface, Material.SaveReplica, that contains parameters relevant only to sales and distribution, is specified. You can then specify in the distribution model that with Material.SaveReplica only data relevant to sales and distribution is transferred to the sales and distribution system.


You can filters BAPIs (parameter filtering and reduction), when you maintain the distribution model. Reduction and filter information are part of ALE Customizing data in the distribution model. BAPI filtering must be explicitly activated, when the BAPI-ALE interface is generated.

The reduction of the actual (asynchronous) BAPI call is carried out as a service in the ALE layer. The reduction service retrieves the details of the filter settings from the distribution model at runtime. For a receiver or a list of receivers the application development can query the list of parameters to be filled before the BAPI-ALE interface is called.

This keeps the read-access to the database as low as possible. (Alternatively the call can take place and it does not affect the result of the filtering.) You can only set up one BAPI reduction for each sender and receiver pair.

Prerequisites

The basic data of the BAPI reduction is maintained by the BAPI developer after the BAPI has been released and before the BAPI-ALE interface is generated.

If a parameter hierarchy is to be used, this has to be specified beforehand. The BAPI developer must create the BAPI as reducible using relevant parameter types. Mandatory parameters and fields must be specified.

The section Filtering Data has a table listing the prerequisites for using filter services.

Fully Reducible Parameters

Only table parameters of BAPIs can be fully reduced. A fully reduced table is an empty table in the receiving system.To fully reduce a table parameter T1 with a checkbox, the following prerequisites apply:
Table Parameter Structure
T1 Q1
T1X Q1X

T1X is a checkbox parameter.


Reducing Parameter Fields

Fields are reduced by converting the obligatory check fields of a BAPI and initializing the relevant fields in the data parameter. The checkboxes must be assigned to the data parameters following the naming and structure conventions.The following prerequisites apply for reducing fields of parameter P1:Table Parameter Structure
P1 S1
P1X S1X

Structures S1 and S1X must have the same number of fields, whereby the names of the fields in both parameters must be identical and in the same order.If P1 has a FUNCTION field or key fields, the FUNCTION field in S1 and S1X and each of the key fields have the same data element. All other fields of the checkbox use the data element BAPIUPDATE.

Procedure
To reduce BAPIs:
1. Create a reducible BAPI that satisfies the above prerequisites.
2. Before generating the BAPI-ALE interface, you have to activate data filtering (option Data filtering allowed).

You can set up the filtering in the distribution model in Customizing by choosing Distribution (ALE) → Modeling and Implementing Business Processes → Maintain Distribution Model.
Result
The generated BAPI-ALE interface enables BAPIs to be filtered as a service in outbound processing.

To avoid unncessary accesses to the database, the BAPI parameters required for the receivers can be determined before the BAPI-ALE interface is called. This is optional and will not affect the results of the filtering.


Defining and Assigning Filter Object Types

Filter object types

are already assigned to some BAPIs in your applications for the receiver and data filtering. You can also define your own filter object types and assign them to a BAPI or to a parameter of a BAPI.
Process Flow
To define filter object types for BAPIs, follow the steps below: • Define filter object types From the SAP menu choose Tools → ALE → ALE Development → BAPIs. You can create filter object types in Data filtering or Receiver Determination. Then choose Define filter object type (Transaction BD95, table TBD11).

Give the filter object type a name and specify a reference to a table field. The reference to a table field is needed to retrieve the documentation from the data element so that customers can get input help when maintaining the distribution model.


For this reason a foreign key must be maintained for the table field. Use the following conventions to name filter object types: - Release 3.0/3.1: Domain name (example: KOKRS for the controlling area) - Release 4.0: Default field name for the data element (example: COMP_CODE for the company code)


For the required data object check whether a name has already been entered in the domain and default field names of the data element. If the fields are empty, a new filter object must be created. Usually the filter object will also appear in the BAPI interface as a field in the transfer structure, for example, bapiachead-comp_code.


If this is the case create the filter object as follows: ALE object type: Field name in BAPI structure, for example, comp_code table name: Name of BAPI structure, for example, bapiachead field name: Field name in the BAPI structure, for example, comp_code

• Defining filter object types to a BAPI From the SAP menu choose Tools → ALE → ALE Development → BAPI Interface. You can assign filter object types to a BAPI in Data filtering or Receiver Determination.

The filter object types allowed for an object method are maintained in each view of Table TBD16. − Receiver Determination. Choose Assign filter object type to BAPI. You can maintain the entries: Object type (from table TOJTB), Method, Filter object type (from table TBD11) Keep in mind that for receiver determination you have to implement a business add-in f to determine values for the filter object type you have defined .

Defining and Assigning Filter Object Types

Choose Assign filter object type to parameter. You can maintain the entries:
Object type (from Table TOJTB), Method, Filter object type (from Table TBD11) Parameter Field name Enter the required data to assign a filter object to an object method for the receiver determination or parameter filtering.


Filtering BAPI Parameters Use

Parameter filtering enables you to manage the number of datasets to be replicated in the BAPI interface using filter objects in the ALE distribution model. The parameters filtered are BAPI table parameters. The lines in the BAPI parameter, that do not match the distribution specifications are filtered out. The filtered table lines are not replicated.

Example: The logical system Q4VCLNT800 is the BAPI server for the BAPI RetailMaterial.Clone. Through the parameter filtering only the plant data of the material plant 001 is to be replicated in this system.

Prerequisites

The prerequisite for this filtering is that a Filter Object Type is assigned to the relevant BAPI in your SAP applications. For some BAPIs SAP has already defined and assigned filter object types.You can also define your own filter object types and assign them to a BAPI (Defining Filter Object Types and Assigning Them to a BAPI .You have to define the valid filter object values in the distribution model. For more information see the R/3 Implementation Guide under Distribution (ALE) → Modelling and Implementing Business Processes → Maintain Distribution Model.

Presently, BAPI parameters can only be filtered for distributing master data via BAPIs called asynchronously. For this reason the required ALE Customizing for parameter filtering is only allowed for asynchronous BAPIs with an ALE IDoc interface.

Parameter filtering is allowed for distributing transaction data via asynchronous BAPIs but for the most cases, it has no purpose.BAPI parameter filtering for asynchronous parameters is always optional. To generate the BAPI-IDoc Interface you must select the Activate checkbox. Otherwise no coding can be generated in the BAPI-IDoc interface.

If a BAPI-IDoc interface has been generated without parameter filtering, you can specify no parameter filtering in ALE Customizing afterwards.

Features

Parameters are filtered dynamically at runtime using the current data in the BAPI table parameters and the distribution conditions specified in the ALE distribution model.

• Reads the specified parameter filter objects in the distribution model
• Reads the interface definition of the BAPI
• Reads the table field values of a table entry for the associated filter objects
• Compares the distribution conditions with the filter objects read out and determines the value of the logical expression
• Deletes table entry
• Examines hierarchy-dependent BAPI parameters and, if applicable, deletes dependent table entries
• For synchronous BAPIs: Calls associated function module and forwards the filtered parameters
• For asynchronous BAPIs: Calls the generated BAPI-ALE interface and forwards the filtered parameters.

RELATED LINKS

ALE PART SIX

MySAP CRM System architecture and design

ALE 4

Implementing Your Own BAPIs

SAP provides a large number of BAPIs. If you want to implement your own BAPIs, you have to use your own namespace.

You have the following options:

• You can develop your own BAPI in the customer namespace.

• You can modify a BAPI delivered in the standard system.

1. Copy and modify the function module belonging to the original BAPI.

2. In the Business Object Repository create a subobject type for your BAPI object type in the customer namespace (Tools → Business Framework → BAPI Development → Business Object Builder).When you create the subobject type the methods of the business object inherit the subtype.

3. Set the status of the object type to Implemented (Edit → Change release status → Object type).

4. You can change and delete the methods of the subtype or enhance them with your own methods.

Notes about Asynchronous BAPIs

If you want to implement an asynchronous ALE business process, you have to Define a BAPI-ALE Interface from the BAPI.If you implement a BAPI as an asynchronous interface, in addition to following the standard programming BAPI guidelines, keep in mind the following:

• The BAPI must not issue a COMMIT WORK command.

• The method's return parameter must use the reference structure BAPIRET2.

• All BAPI export parameters with the exception of the return parameter are ignored and are not included in the IDoc that is generated.

• Status records log the BAPI return parameter values.

After the function module which converts the IDoc into the corresponding BAPI in the receiving system has been called, status records are written for the IDoc in which messages sent in the return parameter are logged.If, in at least one of the entries of return parameter, the field Type in the return parameter is filled with A (abort) or E (error), this means:

• Type A:

Status 51 (error, application document not posted) is written for all status records, after a ROLLBACK WORK has been executed.

Type E:

Status 51 (error, application document not posted) is written for all status records and a ROLLBACK WORK is executed.Otherwise status 53 (application document posted) is written and a COMMIT WORK executed.

Filtering Data

There are two filtering services provided for asynchronous BAPI calls using the BAPI-ALE interface.

Interface Reduction: If you want to reduce the BAPI interface, you do not have to define any filter object types. The BAPI reduction does not have any conditions - it is a projection of the BAPI interface. The developer of the BAPI whose interface is to be reduced must create the BAPI as a reducible using appropriate parameter types. The optional BAPI parameters and/or BAPI fields are deactivated in the distribution model for the data transfer. You can reduce an interface in two ways,

• By fields (using checkbox lists)

• Fully • Parameter Filtering Filter Object Types [Extern] are assigned to the business object method. The valid filter object values must be defined in the distribution model. The BAPI parameter filtering is linked to conditions, it is therefore content-dependent: The lines in table parameters of asynchronous BAPIs are determined depending on the values in the lines (or dependent lines) for the receiver.

Filters are used to define conditions in the form of parameter values that must be satisfied by BAPIs before they can be distributed in ALE outbound processing. The table dataset of a BAPI is determined when the parameters are filtered. Hierarchy relationships between table parameters of the BAPI can also be defined. Distribution by Classes [Extern] is also supported.

For more information see Filtering BAPI Parameters BAPI filtering is the term used for the shared use of both the filter services of the BAPI interface. BAPI filtering is implemented as a service in ALE outbound processing.

Prerequisites for Using Filter Services

The table below lists the prerequisites that the BAPI interface must satisfy, so that ALE filter services can be used. The BAPI can have the following parameter types: Field Reduction Full Filtering Parameter Filtering

1. Unstructured without checkbox

2. Unstructured with checkbox X

3. Single-line structured without checkbox

4. Single-line structured with checkbox X .

5. Multiple-line structured without checkbox

X X

6. Multiple-line structured with checkbox

X X X

7. Multiple-line unstructured without checkbox

X

8. Multiple-line unstructured with checkbox

Note: The fields filled with X satisfy the prerequisites.

Explanation of above table:

1. An unstructured parameter without a checkbox is, for example, a BAPI key field (e.g. the parameter Material in methods of the business object Material). This parameter type cannot be reduced.

2. If there is an unstructured checkbox parameter with the name PX and the data element BAPIUPDATE for an unstructured parameter with the name P, the parameter P is reducible. The parameter is reduced by setting the value of P and of the checkbox parameter PX to EMPTY.

3. A single-line, structured parameter without a checkbox is not reducible.

4. A single-line, structured parameter P with structure S and associated checkbox PX with structure SX can be reduced by fields, provided that:

• S and SX have the same number of fields, which are identical in name and sequence.

• The FUNCTION field and the key fields in S and SX each have the same data element.

• All other fields in SX have the data element BAPIUPDATE.

The FUNCTION field in P and the key fields must be marked as mandatory fields. All the other fields you can chose whether to label them as mandatory. Mandatory fields cannot be reduced. Non-mandatory fields are reduced by setting the field values and the corresponding checkbox to EMPTY.

5. Multiple-line structured parameters (table parameters) without a checkbox cannot be reduced by fields. Parameter filtering and full filtering are possible.If the hierarchy is maintained and, if dependent tables exist in the hierarchy, records of the dependent tables will also be filtered.

6. A multiple-line structured parameter P with checkbox PX can be reduced by fields, fully filtered or filtered by parameters.

• For field reduction the prerequisites under 4 must be met.

• The checkbox PX must lie directly under P in the hierarchy, with identical key fields, so that the corresponding lines from P and PX are filled, when the parameters are filtered.

• If the hierarchy is maintained and, if dependent tables exist in the hierarchy, records of the dependent tables will also be filtered.

7. A multiple-line, unstructured parameter can only be fully filtered and cannot be used in a hierarchy. Parameter filtering is not allowed.

8. Multiple-line, unstructured parameters with a check box cannot be filtered.

RELATED LINKS

ALE PART 6

ALE PART 5

MySAP CRM business intelligence at work

CRM data administration in mysap and business intelligence

ALE 3

Distribution Using BAPIs

Controlling the amount of data sent:

• IDocs can be dispatched in packets. The packet size is assigned in ALE Customizing in accordance with the partner profile.Basis Application Link Enabling Modeling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profile Manually or: Generate Partner Profiles This setting is only effective if you process the IDocs in the background.


Posting of application data and IDoc status If each IDoc or BAPI is processed individually, the data is written immediately to the database. If several IDocs are processed within one packet, the following may happen:

• The application data of the successfully completed BAPI together with all the IDoc status records is updated, provided that no BAPI call has been terminated within the packet.

• As soon as a BAPI call is terminated within the packet, the status of the associated IDoc will indicate an error. Application data will not be updated. Then inbound processing is run again for all the BAPI calls that had been completed successfully.

Provided that there is no termination during this run, the application data of BAPIs and all the IDoc status records are updated. This process is repeated if there are further terminations. Note: Packet processing is only carried out if there is no serialization.

Error handling You can use SAP Workflow for ALE error handling: • The processing of the IDoc or BAPI data causing the error is terminated. • An event is triggered. This event starts an error task (work item).

• Once the data of the BAPI or IDoc has been successfully updated, an event is triggered that terminates the error task. The work task then disappears from the inbound system.

RELATED LINKS

ALE PART FOUR

MySAP CRM System architecture and design
CRM data administration in mysap and business intelligence

ALE 2

The processes in the application layer and the ALE layer are completed on both the inbound and outbound processing sides. The communication layer transfers the data by transactional Remote Function Call (tRFC) or by EDI file interface.

The process can be divided into the following sub-processes:

1. Outbound Processing
• Receiver determination
• Calling the generated outbound function module
• Conversion of BAPI call into IDoc
• Segment filtering
• Field conversion
• IDoc version change
• Dispatch control

2. IDoc dispatch

IDocs are sent in the communication layer by transactional Remote Function Call (tRFC) or by other file interfaces (for example, EDI).
tRFC guarantees that the data is transferred once only.

3. Inbound Processing

• Segment filtering
• Field conversion
• Transfer control
• Conversion of IDoc into BAPI call
• BAPI function module call
• Determination of IDoc status
• Posting of application data and IDoc status
• Error handling

The sub-processes in inbound and outbound processing are described below:
Outbound Processing
On the outbound side first of all the receiver is determined from the distribution model.

Then the outbound function module that has been generated from a BAPI as part of the BAPI-ALE interface is called in the application layer (see also Example Programs with Asynchronous BAPI Calls [Seite 42]).

In the ALE layer the associated IDoc is filled with the filtered data from the BAPI call.The volume of data and time of the data transfer is controlled by the dispatch control.The outbound processing consists of the following steps:

Receiver determination
The receivers of a BAPI call are defined in the distribution model in same way as with synchronous BAPI calls.Before the BAPI or generated BAPI-ALE interface can be called, the receiver must be determined.

When the receiver is determined, the filter objects are checked against the specified conditions and the valid receivers are reported back.If the distribution of the data is also dependent on conditions, these dependencies between BAPIs or between BAPIs and message types are defined as receiver filters.For each of these receiver filters, before the distribution model is defined, a filter object is created whose value at runtimes determines whether the condition is satisfied or not.

For more information see Determining Receivers of BAPIs [Seite 35].Calling the generated outbound function module.If the receivers have been determined, you have to differentiate between local and remote receivers.

The BAPI can be called directly for local receivers. For remote calls the generated ALE outbound function module must be executed so that processing is passed to the ALE layer. The data for the BAPI call and the list of allowed logical receiver systems are passed to this function module.


Programming Notes:

After calling the generated function module the application program must contain the command COMMIT WORK.The standard database COMMIT at the end of the transaction is not sufficient. The COMMIT WORK must not be executed immediately after the call, it can be executed at higher call levels after the function module has been called several times.The IDocs created are locked until the transaction has been completed. To unlock them earlier, you can call the following function modules

:
DEQUEUE_ALL releases all locked objects
EDI_DOCUMENT_DEQUEUE_LATER releases individual IDocs whose numbers are transferred to the function module as parameter values.


Data Filtering

Two filtering services can be used - parameter filtering with conditions and unconditional interface reduction.

• Posting of application data and IDoc status
• Error handling
• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.

• With parameter filtering, table rows that have been filtered out are not included in the IDoc. For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.

For example, the field plant can be converted from a two character field to a four character field.Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.

If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types:
• Fields can be appended to a segment type

• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time: • IDocs can either be sent immediately or in the background.

This setting is made in the partner profile. • If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.

• f entire parameters have been deactivated for the interface reduction, they are not included in the IDoc. If, on the other hand, only individual fields are not to be included for structured parameters, the entire parameters are still included in the IDoc.

• With parameter filtering, table rows that have been filtered out are not included in the IDoc.

For more information see Filtering Data [Extern]. Conversion of BAPI call into IDoc Once the data has been filtered, an IDoc containing the data to be transferred, is created from the BAPI call by the outbound function module Segment filtering Once the IDoc has been created, IDoc segments can be filtered again. This filtering is rarely used for BAPIs.

These are important for converting data fields to exchange information between R/2 and R/3 Systems. For example, the field plant can be converted from a two character field to a four character field.

Standard Executive Information System (EIS) tools are used to convert fields. IDoc version change To guarantee that ALE works correctly between different releases of the R/3 System, IDoc formats can be converted to modify message types to suit different release statuses.

If version change has been completed, the IDocs are stored in the database and the dispatch control is started which decides which of these IDocs are sent immediately. SAP uses the following rules to convert existing message types: • Fields can be appended to a segment type

• New segments can be added ALE Customizing records the version of each message type used in each receiver. The IDoc is created in the correct version in outbound processing. Dispatch control Scheduling the dispatch time:

• IDocs can either be sent immediately or in the background. This setting is made in the partner profile.

• If the IDoc is sent in the background, a job has to be scheduled. You can choose how often background jobs are scheduled.

RELATED LINKS

ALE PART THREE

Customer Relationship Management and mysap an introduction
CRM Management and sales and service strategy of mysap crm

MySAP CRM and customer relationship management
My SAP CRM , Business Scenarios and SAP Solutions