BC619 ALE Technology

BC619 ALE Technology

BC619 ALE Technology

BC619 Release 46D 26.03.2003

DOCPROPERTY "Material" \* MERGEFORMAT

0 0.2 Trademarks:

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation.

IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and OS/400 are registered trademarks of IBM Corporation.

ORACLE is a registered trademark of ORACLE Corporation.

INFORMIX-OnLine for SAP and INFORMIX Dynamic ServerTM are registered trademarks ofInformix Software Incorporated.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology.

JAVA is a registered trademark of Sun Microsystems, Inc.

JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow,SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.comare trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.

0.3 0.4 0.5 1 1.2 1.3 1.4 2 2.2 2.3 2.4 Business processes, business objects and Workflow

In all companies business processes consist of a sequence of work steps in which individual tasks are completed.

When the individual tasks are processed, usually existing data is accessed or new business data is created, for example, customer addresses, bank details, purchase orders. The person processing the data must have authorization to access shared data.

In R/3 Systems business data is structured in business objects.

The processing of business processes must be supported by appropriate workflow functions. The processor of the subsequent task must be notified and if there is an error situation, the correct work steps must be started.

An integrated ERP System such as SAP R/3 automatically fulfils the requirements for shared data access and a workflow controlled process.2.5 Distributed Business Processes

For various reasons it is practical to decentralize business applications for ensuring simultaneous data consistency.

You must ensure that the distributed applications can access shared data. The semantics of this data must be synchronized - updated data must be available in each business environment.

To be able to distribute business processes application data must also be distributed. Business objects are used to distribute this data.

2.6 The increasing globalization of markets has led to the increasing separation of organizational units. Work steps need to be carried out locally but also be part of a distributed business process.

When enterprises are bought or sold business fields must be quickly integrated or deleted.

Business processes are not restricted to one enterprise only. More and more customers and suppliers are being included in business processes. In the Internet age business processes are taking place between companies. A process confined to company boundaries is therefore now unusual.

Autonomous units (e.g. local production plants, sales units) in an enterprise do not want to be dependent on a centrally administered system. There may be several reasons for this:

When structuring a process, flexibility and individuality is very important.

The technical infrastructure for communicating with a central system is not sufficiently developed in all regions for enterprises that operate globally.

Release strategies can be independent and individual.

2.7 Systems that map core processes in logistics (production, plant maintenance, warehouse management system, shipping) have to be available 24 hours every day. The costs of such a high level of system availability should be kept limited to systems providing this core functionality.

2.8 Limited system resources (in particular the DB server) make it necessary to distribute the workload across several systems. Keep in mind that the primary function of ALE is not in handling performance bottle necks. With efficient distribution ALE scenarios can reduce the system load in operative systems (e.g. consolidating nested application data for reporting).

mySAP.com components (New Dimension applications) are to be used.

2.9 Control of the external content server is determined in the content repository definition. Because HTTP is used for control, the SAP system has to register on the HTTP content server with a certificate. This process takes place in the content server administration (transaction CSADMIN) of the SAP Knowledge Provider (Kpro).

2.10 2.11 Analysis of the company organizational structure

Identify the organizational units

Global organizational units: business areas, company codes

2.12 SAP R/3 Business Objects

Definition:

Technical representation of a real world business object:

Customer, vendor, business partner, G/L account

Purchase order, purchase requisition

Material, class

Business processes are modeled using a business object flow.

Encapsulates business logic

Enables access only via defined interfaces (BAPIs, IDoc updating function modules). Complex data structures are assigned to a business object: message type, business APIs.

Hides internal details so that the implementation can be changed externally.

Stored and managed in the Business Object Repository (BOR).

2.13 Structure of SAP R/3 Business Objects

So that SAP business objects can be encapsulated, they are created as entities with different layers.

At the heart of an SAP business object is the core that contains the object data.

The second layer is the integrity layer and represents the business logic of the object. It includes the business rules to ensure consistent embedding in the environment and the constraints for values and applications that can refer to the business object. .

The third layer - the interface layer describes the implementation and structure of the SAP business object and defines the object interface to the external environment.

The fourth layer of a business object is the access layer. This layer defines the technologies that can be used for the external access to the object data e.g. COM/DCOM (Component Object Model/Distributed Component Object Model).

2.14 Each business object belongs to a specific object class depending on its characteristics and its type. These object classes are called object types. For example, all the employees of a company belong to the object type employee.

2.15 All business objects are defined in the Business Object Repository (BOR) within SAP.

The BOR contains two categories of object types:

Business object types

Interface types

BOR objects are processed by the Business Object Builder. The path in the SAP menu is Tools ( ABAP Workbench ( Development ( Business Object Builder.

2.16 The BOR Browser is called from the Business Object Builder. Choose the pushbutton Business Object Repository and then display all the object types.

2.17 2.18 2.19 Technical R/3 objects for IDocs with a message type exist, for example, audit data (ALEAUD) and distribution group (CONDA2)

An IDoc has different characteristics: database table, text, HTML file, XML datastream, RFC call parameters.

2.20 Status records are data records assigned locally to an IDoc - they not part of an IDoc . They are not sent together with the IDoc.

2.21 An example of an IDoc type is MATMAS03

Short description: master material

Release 4.6A

First predecessor MATMAS01

Predecessor MATMAS02

Whether the storing with bar codes is "late" or "early" depends on which step is performed first.

2.22 Message types specify the semantics of application data. The message type is usually based on an EDIFACT message type.

The syntax (structure information) of the data is described in the IDoc type. 2.23 Change Management

Compatible changes are parameter extensions

With incompatible changes new BAPIs must be created: Object.Create -> Object.Create1

2.24 2.25 2.26 BAPIs are defined as methods of SAP business objects in the Business Object Repository (BOR) and implemented as function modules in R/3.

Object-oriented access:Object-oriented access to BAPIs in the BOR can be implemented using various programming platforms, e.g. Windows NT, Win9x, DCOM/COM

RFC access:You can execute direct RFC calls to the function module that forms the basis of the BAPI, either using ABAP or from external development platforms, e.g. by using RFC Class Libraries of C/C++.

2.27 Example: business object BUS2012 - purchase order

2.28 BAPI Explorer (transaction BAPI)

2.29 ALE was originally used to distribute business processes by forwarding the required data and triggering a workflow in the external system.

The focus was on a company's internal distribution scenarios: department-to-department

Using the stable IDoc interface ALE enables business processes that go beyond company boundaries: business-to-business.

ALE is independent of the communication layer and can implement business processes over the Internet.

2.30 2.31 ALE business processes distribute master data and transaction data.

HR Personnel Management SettingsImplementation Guide (IMG): Personnel Management--> Personnel Administration--> Tools--> Optical Archiving

2.32 Outbound function module for the IDoc interface

MASTER_IDOC_DISTRIBUTE

Outbound function modules for asynchronous BAPI calls

ALE__ Inbound function modules for IDoc via tRFC

INBOUND_IDOC_PROCESS (3.x) IDOC_INBOUND_ASYNCHRONOUS (ab 4.x) Inbound function modules for updating message types IDOC_INPUT_MSGTYPE

Inbound function modules for updating asynchronous BAPIs BAPI__2.33 Messaging systems are used increasingly, especially in heterogeneous integrated system networks (R/3 Systems, R/2 Systems, and non-SAP Systems) with a number of permanent interfaces between systems running on different platforms. Data containers (messages) can be consistently exchanged between the systems in near real-time, using a service that can be maintained centrally. Certified products can be found under:http://www.sap.com/csp -> Complementary Products -> ALE Message Handling.

Interfaces for EDI messages are built into the R/3 application components. It is important to note that SAP does not supply or sell EDI conversion/communication software (EDI subsystem), but provides an open, common interface to such systems (CA-EDI). EDI subsystems assume responsibility for all EDI-oriented tasks, such as data convertion, communication, partner profile administration and monitoring of processing. Certified products can be found under:http://www.sap.com/csp -> Complementary Products -> EDI Subsystems.

The ALE concept involves using external converters to connect non-SAP Systems to the R/3 System. External converters are generic format conversion programs. The ALE converter enhances the interface concept in EDI subsystems by offering customer-defined assignments. They recognize the format of any interface structure of a non-SAP System and not just standard EDIFACT or ANSI-X12 formats. Certified products can be found under: http://www.sap.com/csp -> Complementary Products -> ALE Converters.

2.34 If both partners use SAP R/3 Systems and trust each other, the pure use of SAP IDocs for communication is possible without conversion.

ALE converters can be used for internal communication and for communication between enterprises. An assignment step is all that is required. ALE converters are used in external enterprise communication if there is a high level of trust between the partners or if one partner is very dependent on the other.

2.35 2.36 Business Processes and Business Objects: Exercises

Unit: Business Processes and Business ObjectsTopic: Interface Adviser

At the conclusion of these exercises, you will be able to: Understand the structure of the Interface Adviser

Understand the content of the Interface Adviser

You want to gain an overview of existing SAP integration scenarios and available technologies for your interface planning phase.

1-1Log on to SAPNet with the user data (ID and password) given to you by your instructor:HTTP://SAPNET.SAP.COM/INT-ADVISERhttp://sapnet.sap.com/int-adviser 1-1-1Work through the section Introduction.

1-2Become familiar with the structure of the Interface Adviser.

1-2-1Where is the core scenario Sales and Distribution processing standalone?

1-2-2How many variants are explained in detail?

1-2-3What master data is distributed in variant 4?

1-3Which basis technology requirements are mentioned for communication with the R/3-System 3.11 via RFC for external platforms?

Exercises

Unit: Business Processes and Business Objects

Topic: Business Object Repository

At the conclusion of this exercise, you will be able to:

Navigate through the application hierarchy of the business objects in the Business Object Repository.

You want to know where you can find business objects in the R/3 System, and where you can call up information about your attributes, interfaces, and so on.

1-1Open the Business Object Repository Browser for all object types in order to display existing objects in the R/3 System.

1-1-1Expand the hierarchy node of any hierarchy.

1-1-2What do the colors of the objects and the STOP indicator signify?

1-1-3 Display details for the business object sales order (BUS2032).

1-2Use the Business Object Builder in order to identify the object with the technical name BUS1001.

1-2-1What is the key field for this object ?


Topic: Business Application Programming Interface


Find BAPIs directly in the R/3 System, and understand the connection between the definition in the BOR and the actual implementation of the function module.

You want to know where you can find the external interfaces for business objects in the R/3 System, and where you can call up further details about their parameters.

2-1Use the BAPI Explorer to display business objects with BAPIs.

2-1-1What do the different symbols mean?

2-1-2Which business objects in the application project system have BAPIs?

2-1-3Which key field is defined for the business object Network?

2-1-4Which BAPIs does the business object Network provide?

2-2Display the documentation for the business object Network.

2-2-1Display the documentation for the BAPI Getlist.

2-2-2Which function module does the BAPI GetList of Network implement?

2-3Use the alphabetical display to display further information about the business object Applicant.

2-3-1Which instance-independent method is defined for this business object?


Topic: Open BAPI Network


Find further information and products in SAPNet concerning development support for BAPIs.

You want to know how to make a start in developing external access, and how SAP supports you in this.

3-1Visit the Open BAPI Network in SAPNet. Log on using either your own user data or the user data given to you by your instructor.

3-1-1Open the BAPI section.

3-1-2Open the COM section.

3-1-3Open the Java section.

2.37 Business Processes and Business Objects: Solutions


Topic: Interface Adviser

1-1 SAPNet access to http://service.sap.com/int-adviser.Use your SAPNet user ID and password.

1-1-1 Select Introduction(

Read me(

Basics(

How to use

1-2The interface consists of four sections:1.) Data transfer2.) Scenarios3.) Objects4.) Technology

1-2-1You can find the core scenario Sales and Distribution processing (standalone) under

Scenarios (

Core processes (

Sales and Distribution

1-2-2Seven different variants are explained in detail for this core process.1) No availability check is available in R/32) Availability check in R/3 performed against the inventory at delivery3) Availability check in R/3 performed against the inventory at delivery of planned outflows from R/3 sales orders to the external system4) Scheduling the sales orders in the external system5) Scheduling the sales orders against quotas 6) Availability check in R/3 against preplanning7) ATP checks in R/3 against reservations

1-2-3Variant 4 (

Master dataMaterial and customer master data must be distributed.

1-3Return to the homepage of the Interface Adviser and choose technology. In the section Interfaces there is a link to the availability checklist of the basic technologies.

Field nameValues

R/3 Release3.1I

Communication with R/3 Systems (RFCs)Select

Solutions


Topic: Business Object Repository

1-1Tools (

Business Framework (

BAPI development (

Business Object Builder (SWO1)Button: Business Object Repository (SWO3)

1-1-1Expand the node under any application (for example, Real Estate Management, Sales and Distribution) and expand the subnodes.

1-1-2Utilities (

LegendsSTOP indicator: obsolete (please do not use this object type any more)

1-1-3The sales order SalesOrder (BUS2032) is located in the hierarchy under Sales and Distribution (

Sales. Display the details of the business object SalesOrder by double clicking on it.

1-1 Alternative route to the solution in 1-1:Tools (

ABAP Workbench (

Development (

Business Object Builder

1-2 Enter BUS1001 => the text material is displayed

Display the details of the business object Material by double clicking on it.

The MatNr (material number) is displayed as the key field.


Topic: Business Application Programming Interface

2-1Tools (

Business Framework (

BAPI ExplorerSelect the tab multi-level in left-hand section of the screen.

2-1-1Goto (

Display legend

2-1-2Expand the node project system.

You will see three business objects: ProjectDefinition, Network, and WorkBreakdownStruct.

2-1-3Expand the node Network.Only the key field Number : Network Plan Number is defined for this business object.

2-1-4The business object Network provides five BAPIs: ExistenceCheck, Getdetail, Getinfo, Getlist, and Maintain.

2-2Select the node Network in the left-hand section of the screen and choose the tab Documentation in the right-hand section of the screen.

2-2-1Repeat this step for the BAPI Getlist. Select the node Getlist in the left-hand section of the screen and choose the tab Documentation in the right-hand section of the screen.

2-2-2Select the node Getlist in the left-hand section of the screen and choose the tab Detail in the right-hand section of the screen. This BAPI is implemented via the function module BAPI_NETWORK_GETLIST.

2-3Choose the tab Alphabetical in the left-hand section of the screen.

2-3-1Only one instance-independent method is defined for the business object Applicant:CreateFromData.


Topic: Open BAPI Network

3-1http://service.sap.com/bapi

3-1-1Become familiar with the BAPI concept; check which BAPIs are available, or become a member. You can also find up-to-date BAPI information in the BAPI section.

3-1-2The COM section contains information and software relating to COM-based technologies, utilities, documentation, and links to SAP partner sites. On these sites you can find more information and software relating to COM.

3-1-3You can find SAP products and partner products for both Java and BAPIs in the Java section.

2.38 2.39 2.40 Reasons for networking

Computer networks are the technical prerequisite for implementing distributed business processes.The purpose of computer networks are to:

Share data, equipment and system performance over long distances

Guarantee high reliability and availability by providing hardware replacement capacity

Reduce costs since small computers have a considerably higher cost/performance relation than large computers.

Hardware performance can be scaled up (adjustment to the demand for computer power) by adding more computers to the network.

Provides communication across the globe.

All the above reasons bring considerable savings in costs.n. The reasons are similar to the business and technical reasons for distributing business processes.

2.41 A 1978 protocol from the US Defence Ministry established this as the communications standard

TCP/IP communicates data using data packets. As data packets can reach the receiver via any route, this protocol is relatively insensitive to a route failure, provided there are alternative routes.

2.42 2.43 IP Address All network layer protocols have a specific address format. The 32 bit IP addresses of the TCP/IP protocol have the form "199.12.1.1". This format is also called dotted decimal. Each of its four parts corresponds to a decimal number between 0-255 and represents 8 bits.

Part of the IP address identifies the network, the remaining part the individual computer or host within the network.

The part of the address that identifies the host can be defined by a subnetwork mask.

2.44 IP Address Classes

As the whole IP address is only 32 bits long and networks have different numbers of computers, several address classes are created. Address classes assign different numbers of bits to the network component and the host component of the IP address.

2.45 Protocol of the communication-oriented transport layer (layer 4). Part of the packet-oriented Internet Protokoll (IP)

2.46 TCP Ports

TCP uses a 16 bit port number to identify the process on the receiving computer that will process the data packet. Port numbers below 512 are assigned to specified services in Request for Comments (RFCs) and are called "well known ports". Ports under 1024 should only be used by system processes (root user under UNIX).

2.47 Default settings contain document types and concrete employee assignments for these document types (to be customized).

SAP provides a range of programming interfaces to integrate external applications into the SAP System. With these interfaces you can write client/server applications that communicate with SAP Systems. Your external application can function either as the client or as the server to the SAP System (sometimes even as both).

DIAG

With the GUI interface to R/3 you can write a client program that accesses the datastream exchanged between the R/3 application server and its SAPgui.

With the GUI interface your external client program can provide an alternative interface to the standard SAPgui. This can either be a graphical or non graphical interface (e.g. language controlled or Web-based).

Programming using the GUI interface also enables your client program to monitor or record a user dialog with SAPgui images.

RFC

The protocol of the SAP Remote Function Call (RFC) enables you to call ABAP function modules from external applications. An external application that uses the RFC interface, can function as a server or as a client to an SAP System.

Calling an RFC function in an SAP System from an external program is the same in principle as calling an RFC function from another SAP System (from ABAP).

BAPI

SAP business objects provide an object-oriented view of SAP data structures and functions. The Business API (BAPI) is an interface through which you can call the methods of these SAP business objects.

IDoc

The interface Intermediate Document (IDoc) is an SAP standard format for exchanging data between SAP Systems or between an SAP-System and an external application. An IDoc defines an SAP standard data container (template) for sending or receiving data from an SAP System.

File interface (FTP)

EDI (IDoc)

Batch Input The batch input interface enables you to input data into R/3 using R/3 transactions.

Menu path: Office--> Business Documents--> Documents--> Move (TA OAWD)

2.48 2.49 Partner profiles are client-dependent

Partner profiles with the partner type logical system only exist for systems to which the current client sends messages or from which the current client receives messages.

2.50 2.51 2.52 Parameters for R/3 Ports

Version:If you want to communicate using IDocs with SAP Systems of earlier Releases (2.1 to 3.1) or with external systems (e.g. EDI sub-systems), you have to specify the release version in the port description in your system. Then the correct IDoc record types can be sent in outbound processing.

You use the port version to set the release version of the system you want to communicate with. This means:

2.53 R/2 connectionsType 2 entries connect to R/2 Systems. If you create an entry of type 2, you only have to specify the host name; all communication information is already saved in the background information table of the SAP gateway host. If you want you can specify logon details. R/3 connectionsType 3 entries connect to R/3 Systems. If you create an entry of type 3, you have to specify the host name and the communication service. If you want you can specify logon details. As of R/3 Release 3.0 you can choose to specify a load adjustment.

Internal connectionsType 1 entries connect to R/3 Systems that are connected to the same database as the current system. These entries are predefined and cannot be changed. The entry names correspond to the names in the SAP message server (transaction SM51).

2.54 Logical destinations

Instead of specifying a system connection, entries of type L refer to a physical destination. A type L destination can refer to further type L destinations. A type L entry uses information from the reference entry and adds its own information to this. The reference entry usually contains host information while the type L entry contains the logon information. You can also enter a specific user name, password, logon language or client.

A type L entry can refer to other entries of type L.

TCP/IP connections

Destinations of type T are connections to external programs which the RFC Library uses to receive RFCs. The activation type can either be start or registration.

If you choose start you have to enter the host name and the path name of the program you want to start.

If you choose registration, you have to enter a registered RFC program. With an SAP gateway you can register an RFC server program under this ID and then wait for RFC calls from other SAP Systems.

ABAP drivers

Entries of type X specify systems in which device drivers have been especially installed in ABAP. If you create an entry of type X, you have to specify the host name and the ABAP device driver.

2.55 With automatic generation you can change default settings for parameters of partner profiles and R/3 ports. These settings include:

2.56 2.57 Communication and Networks Exercises

Unit: Communication and Networks Topic: Communication Parameters

At the conclusion of these exercises, you will be able to: Find the physical definitions that are necessary for communication between different systems.

You would like to set up communication between R/3 systems.

1. Check the assignment of clients 810 and 811 to the logical system names SALES and PRODUCTION.Client 810:_______________Client 811:_______________2. RFC destinationOn the system SALES:Use the implementation guide (IMG) to view the RFC destination for the system SALES.

Target computer:_______________User:

_______________3. PortsOn the system SALES:Use the implementation guide (IMG) to view the port for the system SALES.

Port:

_______________4. Partner ProfilesOn the SALES system:

Generate a partner profile for the logical system SUBSYS_##.

Set the following outbound partner profile for the partner SUBSYS_##:

Message type:

MATMASOutput mode:

Transfer IDOC immediatelyReceiver port:

CONVERTERRecipient of notifications:Type:

USID:

Set the following inbound partner profile for the partner SUBSYS_##:

Message type:

MATFETProcessing:

Trigger immediatelyProcess code:

MATF

Recipient of notifications:Type:

USID:

2.58 Communication and Networks: Solutions

Unit: Communication and Networks Topic: Communication Parameters

Exercise 1: check assignment

Use the Implementation Guide (IMG):

Tools ( Accelerated SAP ( Customizing ( Project Management ( SAP Reference IMG

Start setting up the logical systems:

Basis components ( Distribution (ALE) ( Sending and Receiving Systems ( Logical systems ( Assign Client to Logical System

Double click on the corresponding client number:

Client 810: SALES

Client 811: PRODUCTION

Exercise 2: RFC destination

Start maintenance of the RFC destination:

Basis Components ( Distribution (ALE) ( Sending and Receiving Systems ( Systems in Network ( Define Target Systems for RFC Calls

Choose R/3 connections.

Double click on the destination IDES_Sales.

The target computer and the user are displayed on the screen.

Exercise 3: Ports

Start the maintenance of ports in the IMG:

Basis Components ( Distribution (ALE) ( Sending and Receiving Systems ( Systems in Network ( Asynchronous Processing ( Assigning Ports (Define Port

Choose Transactional RFC.

The number of the port Sales system is displayed.

Exercise 4: Partner profiles

Start maintenance of partner profiles in the IMG:

Basis components ( Distribution (ALE) ( Modelling and Implementing Business Processes ( Partner Profiles and Time of Processing ( Maintain Partner Profile Manually

Generate the partner profile SUBSYS_##:

Partner number:SUBSYS_##Partner type:LSPostprocessing of authorised users:

TypeUSID

Save the entries.

Setting the outbound partner profile

Under Outbound parameters, choose

New Entries. Message type:MATMASReceiving port:ConverterOutput mode:Transfer IDOC immediatelyIDOC type:MATMAS01Postprocessing of authorised users:

TypeUSID

Save the entries.

Setting the inbound partner profile

Choose F3 back.

Under inbound parameter: Choose New Entries. Message type:MATFETProcessing:Trigger immediatelyProcess codeMATFPostprocessing of authorised users:

TypeUSID

Save the entries.

3 3.2 3.3 3.4 3.5 3.6 The distribution model describes the flow of business objects between logical systems. SAP, non-SAP or other input/output functions can be hidden behind the logical systems.

In the distribution model conditions can be defined for a data flow. These "filter" conditions are used for:

Receiver determination

3.7 The distribution model is client-dependent and may contain one or more views.

The individual views of the distribution model have their own maintenance system that may be different from the logical system of the client.3.8 Maintenance of the distribution model Application Link Enabling Modeling and implementing business processes Maintain distribution model

3.9 Other characteristics of logical systems

Logical systems have a technical name up to 10 characters long and an explanatory short text.

The maintenance of logical systems is an ALE Customizing activity

Application documents with an empty logical system or with the logical system of the current client are interpreted as local documents.

Problems with the logical system name

If the logical system name of a client is changed, the modeling of the ALE message flow may become inconsistent.

If the logical system name of a client is changed, application documents may become invisible because the application classifies them as external documents.

As of R/3 Release 4.5A a logical system must be assigned to each client. For this reason, meaningless logical system names had often been assigned that had to later be renamed. When the logical systems were renamed, the problems with application documents described above occurred.

ALE provides a tool to rename logical system names in application tables. You can find more information in ALE Customizing or in a note.

3.10 Partner profiles are client-dependent.

Partner profiles with the partner type logical system only exist for systems which the current client sends messages to or receives messages from.

For this reason when the partner profiles are generated, ALE only considers connections that contain the logical system of the current client.

3.11 3.12 Data filters are defined as part of modeling the distribution model You define the data filters for a connection in one or more filter groups.

The user or process assigns the document number directly. Internal assignment is done by the SAP System. The document number is based on the the document type. The number range has 20 characters. An important advantage of DMS is the ability to use mixed number assignments. In this case the user or processor assigns an external number that is later changed or updated to an internal number by the system.

The document type is the most central controlling element for the Document Management System. For example, the status network can be setup or object links can be created based on the document type.

Document parts serve to split a document up.

If the filter condition for a mandatory segment is not met, it is either:

The higher-level optional segment is removed and the IDoc is sent

All the higher-level mandatory segments and any existing optional segments are removed in sequence If the header segment is also removed in this process, the IDoc is not sent.

3.13 The document type is the central control element for the Document Management System. It subdivides documents according to characteristics and the organizational processes that follow because of these characteristics. Examples include status network or object links.

Please note the following:

3.14 Selection by classification means that an IDoc is only sent, if the application object belongs to a class defined in Customizing.

The selection by classification setting is part of modeling the distribution model. Maintain the attribute Dependent on class membership in the data filters of a connection.

In ALE Customizing you should set the classes that are to be included in the selection. Assign the classes to be used for distributing the master data to the message type and logical receiving system. The function can be found under Modelling and Implementing Business Processes -> Master Data Distribution -> Distribution Using Object Classes -> Assign Classes to Receiving Logical System.

3.15 If dependencies between message types and/or BAPIs have been defined in the distribution model, message dispatch is dependent on the dispatch of the other messages.

Dependencies are defined as part of modeling the distribution model. You define the dependencies in the data filters of a connection.

3.16 3.17 3.18 3.19 3.20 The task of the IDoc application interfaces is to process outbound and inbound IDocs based on message types. There is a close relationship between outbound processing and the distribution model. The application interfaces for IDocs provide special services for processing messages: Data filtering

Segment filtering

Conversion of global organizational units

3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 The stored document is copied from the archive to the administrators file system.

3.29 3.30 Processing change pointers

Change pointers can be processed manually in ALE Administration or in the background by calling program RBDMIDOC. You can restrict processing to a specified message type. Change pointers can also be processed for extended or reduced message types

3.31 The ALE tool box contains separate programs for monitoring, modeling and error handling.

ALE Audit

Synchronization of Customizing data

Reduction of message types

IDoc recovery following database crash

Conversion of logical system names

3.32 3.33 3.34 ALE Components Exercises

Unit: ALE ComponentsTopic: Model maintenance

At the conclusion of these exercises, you will be able to: Build a distribution model

You would like to model the distribution between two systems and to exchange master data.

1. Set up the distribution customer model TRAINING## on the system 'SALES' in such a way that the message MATMAS is sent to the subsystem SUBSYS_##. (## corresponds to the last two digits of your group number.)2. Ensure that the system 'SUBSYS_##' exists.3. Distribute your model in the logical system 'PRODUCTION'.Exercises

Unit: ALE ComponentsTopic: Distribution of master data

At the conclusion of these exercises, you will be able to: Distribute material master data from the system SALES in the system PRODUCTION

You would like to model the distribution between two systems and to exchange master data.

1. Distribute material directlyOn the SALES system:a) Generate the material MATALE-## as a finished product:

Create the basic data 1/2.

Use the material group 009 and maintain the gross weight, the net weight, the weight unit and maintain a basic data text.

b) Send the material with the message type MATMAS directly to the system PRODUCTION.

c) On the system 'PRODUCTION':View your material.

2. Fetch material mastera) On the system SALESChange the weight of your material.

b) On the system 'PRODUCTION:Fetch your material with the message types MATMAS.

c) View your material.

3.35 ALE Components: Solutions

Unit: ALE ComponentsTopic: Model maintenance

Exercise 1: Set up model

Use the Implementation Guide (IMG):

Tools ( Accelerated SAP ( Customizing ( Project Management ( SAP Reference IMG

Start direct model maintenance by choosing the following:

Basis components ( Distribution (ALE) ( Modelling and Implementing Business Processes ( Maintain Distribution Model and Distribute Views

Switch: display/maintainButton: create model view

Customer model:TRAINING##Button: insert message typeSender:SALESRecipient:SUBSYST_##Logical message type:MATMASSave the model.

Exercise 2: Does system SUBSYST_## exist?

To confirm that system SUBSYST_## exists, choose:

Basis Components ( Distribution (ALE) ( Sending and Receiving Systems ( Define Logical Systems.

Exercise 3: Distribution of the model

For distribution, choose:

Basis Components ( Distribution (ALE) ( Modelling and Implement Business Processes ( Maintain Distribution Model and Distribute Views

Process ( Model View ( Distribute ( Training## ( and target system PRODUCTIONSolutions

Unit: ALE ComponentsTopic: Distribution of master data

Exercise 1: Sending material

Use the menu to generate the new material.

Logistics (

Materials Management (

Material Master (

Material (

Create (Special) (

Finished Product

Material:

MATALE-##Industry:

Mechanical engineeringChoose view selection.Choose:

Basic data 1/2Choose Next.

Update the values for your material.

Save the entries.

Send your material.

Go to the ALE menu:Tools ( ALE ( Master Data Distribution ( Cross-application ( Material ( Send

Material:MATALE-##Message type:MATMASLogical System:PRODUCTIONc) Display your material in the system PRODUCTION.Log on to the system PRODUCTION.

Display your material.

Logistics (

Materials management (

Material master (

Material (

Display (

Display current status

Material:MATALE-##Exercise 2: Call up material master

Change the weight of your material.

Log on to the system SALES.

Logistics (


Material Master (

Material (

Change (

Immediately

Material:MATALE-##Selected view:Basic data 1/2Change the weight.

Save your entries.

Call up your changes.

Log on to the system PRODUCTION.

Tools ( ALE ( Master Data Distribution ( Cross-application ( Material ( Get

Material:

MATALE-##Message type:

MATMAS Display material.

Display your material.

Logistics (


Material Master (

Material (

Display (

Display Current

4 4.2 4.3 4.4 IDoc services tailor messages to the requirements of the receiving logical system. Business factors and the organizational structure play an important role in these requirements: data filtering, global organizational units, field conversion.

IDoc services distinguish between IDocs defined from message types (< 4.x) and IDocs of the generated interface for asynchronous BAPI calls (> 4.x).

4.5 Sequence of IDoc services in outbound processing:

Data filtering (IDOC_DATA_APPLY_FILTER_VALUES)

Segment filtering (ALE_IDOC_SERVICES_APPLY_OUT) Conversion of global organizational units

The messages to be created are proposed in the sales documents using the condition technique.

For output determination using the condition technique, condition records must be available for the various message types. The transmission medium, the send time and the partner role are defined in the condition record.

Version change (ALE_IDOC_SERVICES_APPLY_IN) Segment filtering

4.6 Local organizational units must be assigned to global organizational units in your systems to ensure that organizational units are standardized in the distributed environment.

Make the settings for converting global organizational units in ALE Customizing under Modelling and Implementing Business Processes. Cross-application Settings Set global organizational units4.7 Setting data conversion between the sending and receiving systems

The tool enables field contents to be converted and mapped from a sender field to a receiver field. Organizational units, units of measurements and customer-defined fields can be transferred from one system to another.

A generic R/3 tool is used for defining and maintaining rules.

The settings for data conversion are made in ALE Customizing under Modelling and Implementing Business Processes -> Converting Data Between Sender and Receiver.

4.8 The settings for IDoc version change are made in partner profile maintenance in field Segment release in IDoc type. Refer to the F1 help.

If the field is empty, the segment definition currently assigned to it is used. The current segment definition does not need to have been released. Following an upgrade the segment definition can change.

The definition used for each segment type from the current IDoc is the definition that was actually released in the Release specified. Following an upgrade the same segment definition can still be used,, if you specify the release.

The setting made here does not take into account that an earlier function module has to be called for tRFC communication between 4.x and 3.x systems. This is specified in the port settings by the IDoc record type version. 4.9 4.10 IDoc Services: Exercises

Unit: IDoc ServicesTopic: Data conversion

At the conclusion of these exercises, you will be able to: State a rule for data conversion in communication between two systems Distribute message types via filters.

You want to establish a rule which allows data to be adapted during communication.

1. Creating rules

In the SALES system:Generate your own message type ZMA0XX:

Derived from:MATMAS (Master Material).Active segments:Everything that appears after you click on the first segment + the fields from E1MARAM, E1MAKTM, E1MARCM, E1MTXHM and E1MTXLM. Define and maintain a conversion rule CONV_##. Set a constant value for this (your) message type in the field Old Material Number (field BISMT in segment E1MARAM).

Replace net weight with gross weight.

2. Modelling:

Set your distribution model and the communications parameters in such a way that you can send your message type from the system SALES to the system PRODUCTION.

Set the conversion on the outbound side for communication with the system PRODUCTION.

Set up the conversion on the inbound side for communication with the system SALES. Send an IDoc with your message type to the system PRODUCTION and use the IDoc list to check the result of the conversion.

Set the filter material type = HAWA for your message type.

Send an IDoc with your message type to the system PRODUCTION and use the IDoc list to check the result of the conversion.What happens and why?

Delete the filter.

4.11 IDoc Services: Solutions

Unit: IDoc ServicesTopic: Data conversion

Exercise 1: Define conversion rules

Maintain your message type.

Start IDOC reduction in IMG:

Basis Components ( Distribution (ALE) ( Modelling and Implementing Business Processes ( Master Data Distribution ( Scope of Data for Distribution ( Message Reduction ( Create Reduced Message Type

View (NachrTyp):

ZMA0##Choose Create.

Model:

MATMASChoose Next.

Enter a short text.

Choose Next.

Open the structure and mark all segments as selected.Note: the fields within the segment on the uppermost level must also be selected. . Define the rule CONV_##.

Basis components ( Distribution (ALE) ( Model and implement business processes ( Data conversion between sender and recipient ( Define rules for the IDoc segment name

Choose New Entries.

Conversion ruleCONV_##Segment type

E1MARAMSave your entry.

Update the rule.

Basis components ( Distribution (ALE) ( Modelling and Implementing Business Processes ( Converting Data between Sender and Receiver ( Maintain Rules

Conversion rule

CONV_##Choose Maintain.

Choose the field BISMT (Old mat. number).

Specify the characteristic value of the constant.

Choose Enter.

Enter the sender value BRGEW in the receiving field NTGEW (net weight). Save your entry.

Assign rules to a message type.

Distribution (ALE) ( Modelling and Implementing Business Processes ( Converting Data between Sender and Receiver ( Assign Rule to Message Type

Log. message type

ZMA0##Choose Next.

Choose New entries.Partner type (sender):

LSSender

:SALESPartner type (recipient):

LSRecipient

:PRODUCTIONSegment type:

E1MARAMConversion rule:

CONV_##Save your entry.

Exercise 2: Modeling, test conversion

In your Model Training_xx, model the exchange of your message type ZMA0_xx from the system SALES to the system PRODUCTION, as explained in the exercise for Unit 4, and create the partner profiles as in Unit 3.

Model:

Training_xxSender:

SALESRecipient:

PRODUCTIONMessage type:

ZMA0##Generate the partner profile in the system SALES:

Setting the outbound partner profile.

Under outbound parameter, choose

New Entries. Message type:

ZMA0##Receiving port:

Production systemOutput mode:

Transfer IDOC immediately.IDOC type:

MATMAS01Postprocessing of authorised users:

Type

USID

Save the entries.

Generate the partner profile in the system PRODUCTION:

Setting the inbound partner profile

Under inbound parameter: Choose New Entries. Message type:

ZMA0##Processing:

Trigger immediatelyProcess code

MATMPostprocessing of authorised users:

Type

USID

Save the entries.

Send your material with your message type directly from the system SALES to the system PRODUCTION.

Use the IDOC list in the system PRODUCTION to check the conversion.

Create filter:

Maintain your distribution model.

Choose display/change.

Open your message types for the system PRODUCTION.Double-click on: no active filters.

Choose Create Filter Group.

Enter MatArt = HAWA.Save the model.

5 5.2 5.3 5.4 5.5 Delays in transferring IDocs may result in an IDoc containing data belonging to a specific application object arriving at its destination before an "older" IDoc that contains different data belonging to the same object. Applications can use the ALE Serialization API to specify the order IDocs of the same message type are processed in and to prevent old data from being posted if processing is repeated. IDocs from interfaces generated for asynchronous BAPI calls cannot be serialized at IDoc level because the function module for inbound processing does not use the ALE Serialization API. ALE provides two function modules to serialize IDocs, which the posting function module has to call:

IDOC_SERIALIZATION_CHECK: Checks the time stamps in the serialization field of the IDoc header. IDocs are read and organized according to serialization criteria. The IDoc data, IDoc control records, and IDoc serialization data are returned in the results. The control records and serialization data are sorted according to serialization criteria.

IDOC_SERIAL_POST: Updates the serialization table. A record is written in table BDFL for each serialization object.

5.6 With master data distribution, interdependent objects are often distributed together (purchasing info record with vendor and material, for example). Serialized distribution is only used to transfer changes to master data. IDoc message types are assigned to serialization groups according to the order specified for their transfer. Master data is distributed in exactly the same order. If all the IDocs belonging to the same serialization group are dispatched successfully, the sending system sends a special control message to the receiving system. This control message contains the order IDocs are to be processed in and starts inbound processing in the receiving systems.

An example is the purchasing info record with vendor and material. To avoid any processing errors, the vendor and material must be created in the receiving system before the purchasing info record.

5.7 Serialized messages may be of different types (for example, create, change, cancel messages). All messages here relate to one special application object Transfer errors (IDoc sequence mixed up) and inbound posting errors (IDoc cannot be posted due to Customizing errors) no longer affect the sequential order.

A unique serial number is assigned to each outbound message for the application object in question. When processing inbound IDocs, the ALE layer determines whether a given IDoc can now be posted or whether other IDocs have to be posted first. (In this case, the IDoc is assigned status 66 and must be posted again with the program RBDAPP01.)

Objects are assigned to messages by the application. To implement serialized distribution using objects, the following settings must be made in Customizing:

Activate outbound object types

Activate inbound object types

To prevent posting coming to a standstill, the object types must be activated in both systems!

5.8 5.9 5.10 The selection by classification setting is part of modeling the distribution model. Maintain the attribute Dependent on class membership in the data filters of a connection.

In ALE Customizing you should set the classes that are to be included in the selection. Assign the classes to be used for distributing the master data to the message type and logical receiving system. The function can be found under Modelling and Implementing Business Processes -> Master Data Distribution -> Distribution Using Object Classes -> Assign Classes to Receiving Logical System.5.11 5.12 5.13 With ALE audit, the audit data is sent using message type ALEAUD.

5.14 5.15 5.16 Special Functions: Exercises

Unit: Special FunctionsTopic: Sending Messages Using Classes

At the conclusion of these exercises, you will be able to: Send messages using the filter class membership

You want to distribute master data among systems that are filtered according to their class membership.

1. Sending Via Classes

In the system SALES: create a class class_## for materials.

Create a class with class type ALM.

Assign your class to the logical system PRODUCTION. Add the facility for distribution among classes in your distribution model to your message type.

Send the material with your message type to the system PRODUCTION.

Check the result.

Allocate your material to your class.

Send the material from your class with your message type to the system PRODUCTION.

Check the result.

5.17 Special Functions: Solutions

Unit: Special FunctionsTopic: Sending Messages Using Classes

Exercise 1: Sending using classes

Generating a class

Basis Components( Distribution (ALE) ( Modelling and Implementing Business Processes( Master Data Distribution( Distribution Using Object Classes

Choose Maintain Classes.

Choose the class type:ALMClass:CLASS_##Choose Enter.

Enter a name.

Save your entry.

Assign your class to the system PRODUCTION.

Basis Components( Distribution (ALE) ( Modelling and Implementing Business Processes( Master Data Distribution ( Distribution Using Object Classes ( Assign Classes to Receiving Logical System

Logical System:

PRODUCTIONChoose Next.

Choose New Entries.

Type:

ZMA0##Class:

CLASS_##Push/Pull

2Save your entry.

Include class in distribution model.

Basis Components( Distribution (ALE) ( Modelling and Implementing Business Processes ( Master Data Distribution ( Distribution Using Object Classes ( Model Distribution Using Classes

Maintain your distribution model.

Choose display/change.

Open your message types for the system PRODUCTION.Double-click on: no filter set up.

Choose Create Filter Group.

Check independent of class.

Save the model.

Send your material.

Tools ( ALE ( Master Data Distribution ( Cross-application ( Material ( Send

Message type:

ZMA0##Logical System:

PRODUCTIONExecute the program.

Check the result.

Use the IDOC Monitor to check that the message has arrived in the system SALES.

Assign your material to your class.

Logistics ( Materials Management ( Material Master ( Material ( Create (Special) ( Immediately

Enter Material Number ( Select View(s)( Classification

Material:

MATALE-##Class type:

ALMChoose Enter.

Class:

Class_##Save your entry.

Send your material.

Tools ( ALE ( Master Data Distribution ( Cross-application ( Material ( Send

Message type:

ZMA0##Logical System:

PRODUCTIONExecute the program.

Check the result.

Use the IDOC Monitor to check that the message has arrived in the system SALES.

6 6.2 6.3 6.4 How does ALE audit work?

ALE audit provides the sending system with information on the processing status of the receiving system.

ALE audit uses the asynchronous IDoc interface to send messages with status information to the sending system. The confirmation has the message type ALEAUD.

Audit confirmations are either sent periodically via a batch job or sent directly.

6.5 6.6 The storage system searches for the search terms in the description file and if the search is successful, indicates the relevant position in the data file

In the distribution model, maintain a link to message type ALEAUD in the opposite direction for each link of a message type to be monitored.

Maintain the filter object type message type as the data filter for ALEAUD.

6.7 If audit information is available, the IDocs in the sending system have the status

39IDoc in receiving system (ALE service)

6.8 Because of company policy

Influence on the business processes

6.9 Distribution model for synchronizing Customizing data

The ALE distribution model describes which Customizing objects are distributed and the systems that data is distributed from and to. This model is defined in one central system and distributed from here to all other participating systems. The distribution is modeled in message type CONDA2. The distribution groups relevant for a logical system are specified as values of data filters.

6.10 Modeling (functions of ALE Customizing)

Determines project-specific Customizing objects relevant to message types and assignment to distribution groups

Creates a distribution model for Customizing objects

Distributing the DM: Creates object lock for ALE Customizing objects in the decentralized systems

6.11 The tool can only process client-dependent Customizing objects of the category CUST. The objects must be defined in transaction SOBJ. The following object types can be used:

The units can be divided as follows:

Units which describe how to configure the IDoc Interface

The unit "Test" describes an important step in the process of configuring the IDoc Interface. The emphasis is placed on the implementation of the test programs in the data flow.

C

View cluster

The Customizing objects to be distributed can be defined further using the object key. This allows you to distinguish between central and local instances of a Customizing object.

6.12 Define number rangeUnique control records are generated using the number range.

Implementation Guide (IMG): Basis Components --> Basis Services-->SAP ArchiveLink -->Basic Settings -->Maintain number ranges Create QueuesQueues are activated and the queue administrator is entered. This process should be a part of the installation routine of the storage system. Absence of activated queues could lead to irreparable errors (the print list then has to be generated and stored again).

Implementation Guide (IMG): Basis Components --> Basis Services-->SAP ArchiveLink -->Basic Settings --> Create queues Schedule a Job The job periodically executes the individual queues. You should note that the job is only scheduled during the daily online work when it does not hinder this. For performance reasons it is not recommended to schedule jobs more frequently than once every fifteen minutes.

Implementation Guide (IMG): Basis Components --> Basis Services-->SAP ArchiveLink -->Basic Settings -->Schedule jobs

6.13 Function 'Display stored document' -->

6.14 Two special IDoc application areas should be defined:

6.15 Outbound processing includes:

Generating the corresponding outbound IDoc

Finding the partner and the port

6.16 When reducing a message type, a new message type is created in the customer namespace.

The reduced message type refers to an existing message type, which is classed as reducible, and its associated IDoc basic type. The IDoc segments and fields to be distributed can be chosen on the basis of an IDoc basic type.

The inbound function module of the IDoc basic type is assigned to the reduced message type.

For the IDoc to be posted correctly on the receiving side, the receiving system needs to know the settings for the reduced message type.

The message type information can be entered in a transport request and then imported.

6.17 In ALE Customizing, choose Modeling and Implementing Business Processes Master Data Distribution Scope of Data for Distribution Message Reduction to call up the two points Create Reduced Message Type and Generate Transport Request for Message Type.6.18 6.19 6.20 For information on converting the logical system name of a client, refer to ALE Customizing under Sending and Receiving Systems Logical Systems Convert Logical System Names in Application Tables and to the online library. Authorizations

To run the report, you must be authorized to convert logical system names (authorization object B_ALE_LSYS).

Test mode

You are advised to start the conversion in test mode. If you activate the test run selection field, all relevant tables will be analyzed and the number of entries contained in the tables will be determined. These will then be output in a list. If the new logical system name is already available in the relevant tables, the system queries whether the conversion is to be continued or not. You must check the table in which this logical system name was found and determine whether you want to perform the conversion for these entries. If this is not the case, the conversion must be terminated.

6.21 6.22 The IDoc recovery uses two transactions

BDRC to determine the recovery objects BDRL to process the recovery objects

6.23 Before the start of the transaction, the following message flows to the distribution model are maintained. S1 is the system that has crashed.

S1 - RCYFET -> S2

S1 Administration > Administration > Data Retention Tool. Data for technical linking is determined in the port definition for the IDoc Interface. So that a port can be used, settings outside of the IDoc Interface must be made.

The port definition for the port type "file" includes

Instead of the outbound file, you can also store a function module, which dynamically generates names and thus helps to prevent files from being over-written. You can also use logical file names: You should also see the F1 Help for the field.

7.10 The status monitor offers extended selection possibilities for the display:

Business object

7.11 7.12 Since it is geared to application objects, manual IDoc processing is very suitable as a monitoring tool for ALE application specialists. It allows

IDoc selection on the basis of a variety of criteria

Detailed display of the IDocs

Triggering of further processing

For Release 4.6A/B, only incorrect messages are displayed in "Manual IDoc processing".

7.13 Processing serialization groups for message types

7.14 7.15 Administration Exercises

Unit: AdministrationTopic: ALE Monitoring

At the conclusion of these exercises, you will be able to: Administer sent messages.

You want to monitor the exchange of your messages.

In the SALES system:Change your material (the short text) again and send it to the PRODUCTION system.

Your material was sent to the PRODUCTION system with an IDoc. What is the number of this IDoc?

IDOC number:

____________________ Use the links to view the material in the IDoc list. Use IDoc tracing to ensure that the number you obtain from this list is retained in the PRODUCTION system.IDOC number:

____________________ View the material obtained from IDoc tracing in the PRODUCTION system.7.16 Administration Solutions

Unit: AdministrationTopic: ALE Monitoring

Exercise 1: IDoc List

Use the IDoc List.

Tools ( ALE ( ALE Administration ( Monitoring ( IDoc List

Select all IDocs with the message type MATMAS that were created today.

To find the IDoc with your material, examine the contents of the data records.

Note the IDOC number.

Exercise 2: Linking

View your material in the IDoc display by selecting System ( Links.

Exercise 3: IDoc Tracing

Use IDoc tracing:

Tools ( ALE ( ALE Administration ( Monitoring ( IDoc List

Logical message type:

ZMAxxReceivers partner type:

LS

LSReceivers partner number:

LS

PRODUCTIONExamine your IDoc number in order to receive the number of the corresponding IDoc in the receiving system.

View your material in the IDoc display by selecting System ( Links.

8 8.2 8.3 8.4 8.5 8.6 8.7 The FB EXIT_SAPLBD11_001 is called during IDoc outbound processing in the form routine CHANGE_IDOC_VERSION and during IDoc inbound processing in the form routine IDOC_CONVERT_VERSION_INBOUND. The call hierarchy is as follows

Outbound:When distributing via message types, the user exit is called while the function module MASTER_IDOC_DISTRIBUTE is being processed. If the distribution is performed by the asynchronous BAPI call, the user exit is executed in the sequence ALE_IDOCS_CREATE.

FUNCTION MASTER_IDOC_DISTRIBUTE -> FORM IDOC_SELECTION_AND_SERVICES -> FUNCTION ALE_IDOC_SERVICES_APPLY_OUT -> FORM IDOC_CONVERT_VERSION_OUTBOUND -> FORM CHANGE_IDOC_VERSION -> FUNCTION EXIT_SAPLBD11_001

FUNCTION ALE_IDOCS_CREATE ->FUNCTION ALE_IDOC_SERVICES_APPLY_OUT -> FORM IDOC-CONVERT_VERSION_OUTBOUND -> FORM CHANGE_IDOC_VERSION -> FUNCTION EXIT_SAPLBD11_001

Inbound

FUNCTION INBOUND_IDOC_PROCESS -> FUNCTION ALE_IDOC_SERVICES_APPLY_IN -> FORM IDOC_CONVERT_VERSION_INBOUND -> FUNCTION EXIT_SAPLBD11_001

8.8 9 9.2 9.3 9.4 9.5 Partner profiles can also be sent via the special IDoc type SYPART01. A partner profile for this IDoc type with the "logical" message SYPART is therefore a prerequisite.

9.6 If the same master data is changed several times, only the last change pointer is used to create the master data IDoc. This minimizes the number of IDocs dispatched.

To create change pointers, in ALE Customizing you have to activate change pointers generally as well as for individual message types.

9.7 Creating and transferring the IDoc to the communication layer at separate times improves system performance

The outbound processing mode Collect IDocs is set in the partner profiles

9.8 The following options are available in the test tool for both inbound and outbound processing:

Mass testing: Several copies of the edited IDoc are sent for processing. If the relevant flag is not set, only one copy is sent.

In addition, the following options are available for inbound processing:

ALE inbound processing splits the IDoc packets into individual IDocs.

9.9 This is particularly advantageous for sending mass data

9.10 There are no benefits of creating IDocs in parallel for distributing transaction data in ALE, because this mainly involves single events which cannot be accelerated by running dialog processes at the same time.

The server group is a list of the application servers, whose available dialog processes are used to create IDocs. Two dialog processes remain unused on every application server in a server group.

9.11 9.12 9.13 "6"EDI (Electronic Data Interchange), that is, without distribution model

The EDI program for message processing is started with these parameters: RSNASTED, with the form routines EDI_PROCESSING or ALE_PROCESSING.

IDocs are transferred individually from program RSNASTED when using output modes "1" and "2" (field OUTMOD in the control record).

9.14 You can process IDocs that are ready for transfer (status 64) manually in ALE administration (status monitor BD87) or by scheduling the program RBDAPP01.

9.15 9.16 9.17 You can specify the packet size of message types in Customizing for ALE: Modeling and Implementing Business Processes Partner Profiles and Time of Processing Maintain Partner Profile Manually

From Release 4.5B, the main relevant communication types for displaying and storing documents are those mentioned in the slide.

The previous communication standard 'ICC', present in the first line of the SAP ArchiveLink viewer using Archive DLL, is still available, but in the background.

9.18 INPUTTYP contains the code for posting function modules. INPUTTYP can contain the following values:

"0", for function modules which process IDocs in packets

When IDocs are received, they are first saved in the database. In a second and independent step, they are processed further (for port types "file", "XML", "CPI-C"). This is made possible by the workflow event concept: If IDocs are saved in the database, an event is created , which waits for the "receiver" in the system. The "receiver" (a function module) finds the event and triggers inbound processing. As a result of this step, the function module has used the event, which no longer exists in the system. The Workflow Manager determines when the receiver starts to search for events: There is therefore an interval between the data being saved and further processing being initiated (asynchronous processing).

To display the function module INPUTTYP, on the ALE Development screen, choose IDoc Inbound Function module attributes (BD51). You must therefore activate the event-receiver linkage in the IMG for the IDoc Interface.

OLE communication is most frequently used in connection with the front end components of the particular storage system provider. The storage system provider or executive business partner is responsible for notifying the SAP System of the OLE classes of these components and for maintaining the communication sequence for displaying and storing documents.

The OLE communication can also be used to integrate OLE automation 2.0 compatible standard PC components in the scenarios. OLE Automation 2.0 offers a wide range of possibilities for controlling the front end components from the SAP System.

For the front end components named above there are generation functions in the protocol maintenance which produce a simple local display of the document.

9.19 9.20 10 10.2 10.3 10.4 S_IDOC_ALL

S_IDOCMONIWFEDI: Access to IDOC monitoring

S_IDOCCTRL WFEDI: General access to IDOC functions

S_IDOCDEFT WFEDI: Access to IDOC development

S_IDOCPORT WFEDI: Access to port profiles (IDoc)

S_IDOCPART WFEDI: Access to partner profiles (IDoc)

S_TRANSPRT

10.5 10.6 10.7 10.8 11 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 12 12.2 12.3 12.4 12.5 12.6 12.7 12.8 12.9 Rajeev Kasturi and Arvind Nagpal are independent ALE consultants

12.10 12.11 12.12

_962539304.unknown