2. Application Linking And Enabling Last modified by: Bunty Jain â SAP ABAP, Delhi, India, IT SAP Training [email_address]
3. Distributed Process An introduction Last modified by: Bunty Jain â SAP ABAP, Delhi, India, IT SAP Training [email_address]
4. When a part of a business process is conducted in one system and another part of the same business process in another system, such procedure is termed as a distributed process. Distributed Process. Last modified by: Bunty Jain â SAP ABAP, Delhi, India, IT SAP Training [email_address]
9. SAPâs solution for its distribution requirements : Application Linking & Enabling.
10. Application Linking & Enabling. SAP introduced ALE to to support a distributed yet integrated environment. ALE allows for efficient and reliable communication between distributed processes across physically separate systems. ALE is based on application to application integration using message control architecture.
11. Application Linking & Enabling. ALE is not based on any data replication technique. ALE architecture is independent of participating systems. This allows SAP to allow SAP to Non-SAP communication also. This allows third party applications to integrate with SAP using ALE at data distribution level. IDOCs constitute a major component of ALE. Release upgrades are supported by ALE. Features
12. Provisions of the standard system for ALE Pre-configured Master Data Scenarios Several master data objects in SAP have been enabled for ALE. Master data is the critical information that needs to be shared between several applications in a company. ALE is used to transfer both master & transactional data
17. Idoc type is subdivided into so many segments. Each segment will have one or more fields. Group functionally related fields into segments. Then use segments to create the IDOC. Structure description MATMAS05 Material master E1MARAM General data E1MAKTM Short text E1MARMM Unit of measure E1MARCM Plant data Field list E1MARAM _ MATNR Material no. _ MTART Material type _ MBRSH Industry sector _ MATKL Material group _ WRKST Basic material ...
For converting the text IDs: Purchasing and Sales use different text IDs. If order texts are to be copied to the sales orders, a conversion must take place. This can be performed using the ALE conversion. For the purchase order (ORDERS) and the purchase order change (ORDCHG), conversions must take place at header and item level. These conversions can be carried out by generating a conversion rule for the document header (segment E1EDKT1) and the item (segment E1EDPT1). When defining this rule, use TDID for the recipient field. The assignment rule is GROUP, the sender field is TDID. A comparison of IDs for the purchase order and sales order is provided in the documentation on the âStock Transfer Between Distributed Systemsâ Scenario in the IMG. EDI settings: 1. EDI settings for incoming sales orders -Configuration of EDI partners (table EDPAR). Derivation of internal partner numbers from the combination sold-to party - partner role - external partner number -Maintenance of possible partner roles -Derivation of the sales area (table EDSDC) from the combination customer - vendor. If the sales area is specified in the IDoc, the table is not required. 2. Message handling for incoming orders Messages that are output for an inbound IDoc (if the IDoc contains conditions or payment conditions, for example) can be defined as information, warnings, or document blocks. 3. Conversion from SAP item category to IDoc item category An item category can be provided in the IDoc. This is converted to an SAP item category via the EDPST table. (If no item category is specified, the SD item category is determined in the standard manner).
The distribution of systems makes it necessary to be able to identify every system individually within a network. The "logical system" is used to do this. ALE Configuration Phase 4-2 A logical system is an application system within which the applications are co-ordinated to work in one database. In the SAP sense of the word, a logical system corresponds to a client. A logical system needs to be set up for each client that the system, on which you are working, needs to communicate to via ALE. In the following steps, you must define every client as a logical system by first of all defining logical systems and then assigning the clients in question to the corresponding logical systems. Note: Assignments must be unique (that is, a client may only be assigned to one logical system. Several clients must never be assigned to the same logical system. The same applies to pre-production systems and production systems: the pre-productive system must be assigned to a different logical system than the productive system.
Maintain logical systems (Client independent) 1. In the IMG, choose Cross-Application Components -> Distribution (ALE) -> Basic Configuration -> Set up logical system -> Maintain logical systems 2. To create a logical system, choose Edit -> New Entries . 3. Enter a name for the logical system according to the ALE Naming Standards document 4. Enter a clear description for the logical system. If you want to change this short text for a logical system, please proceed as follows: a) Select the appropriate line. b) Choose Edit -> Change field entries. 5. Enter the new short text. 6. Choose Replace. 7. Save your entries. 8. Repeat steps 2-4 for the different clients.
Allocate logical systems to the client This step only needs to be performed for the clients that reside on the box where you have just created the logical systems. For those logical systems that refer to clients that exist on other systems, the logical system will be linked to the client on its respective system. E.g., ALExxxCyyy will be linked to client yyy on system xxx. 1. In the IMG, choose Cross-Application Components -> Distribution (ALE) -> Basic Configuration -> Set up logical system -> Allocate logical system to the client 2. Select the relevant client. 3. Choose: Goto -> Detail . You branch into the detail screen. 4. In the field Logical system, specify the name of the logical system to which you want to assign the selected client, as per the naming conventions. 5. Save your entries.
This must be set up for all the logical destinations manually. RFC destinations are client independent. The Remote Function Call is controlled via the parameters of the RFC destination. The RFC destinations must be maintained in order to create an RFC port. The name of the RFC destination should correspond to the name of the logical system in question. EG. ALExxxCyyy Procedure 1. Execute SM59 2. Click on R/3 links and choose Edit -> Create; 3. The RFC destination name must be the same as the logical system name in order for the port to be automatically generated. 4. The type of RFC destination is 3. 5. Enter the required parameters dependent on the type. ⢠For an R/3 link, that is, for example, the name of the RFC destination, the name of the partner machine, logon parameter ALE-BATCH with password init. 6. Select the Destination -> TRFC options function from the menu. 7. Enter the value 'X' into the 'Suppress backgr. job in case of comms. error' field. 8. Save and exit. Notes on the transport The maintenance of the RFC destination is not a part of the automatic transport and correction system. Therefore the setting has to be made manually on all systems.