Using ALE with Middleware
What is Middleware?
The word middleware has several meanings. It can be any one of a confusing array of message-queuing, application development environments, object development environments, database access, distributed transaction processing, messaging communications, or Remote Procedure Call (RPC)-based communications.
For the purposes of distributed applications, and Enterprise Application Integration (EAI) we will be talking about Message-oriented Middleware (MOM).
MOM is a system or set of systems providing the services needed to manage the execution of applications in a distributed environment.
According to the Gartner Group, 40% of the average IT budget is spent on systems integration. This has two implications: that systems integration is important, and that it is difficult.
The primary aim of middleware is to provide easy connectivity between different applications.
Common characteristics of Message Oriented Middleware include:
q Real-time data transfer
q Messages are based on business rather than technical design considerations. An example of a message might be “Create Sales Order”
q Although real-time, the applications are usually processed asynchronously, using queues for data transfer. Once the sending process places a message on a queue, then it can forget about it, and continue with other tasks. Similarly, the receiving process only needs to pick up the message when it is ready to process it.
Some examples of products in the middleware area are NEON MQSI, MQ-Series, and Mercator.
EAI Using a Message Broker
Central to the middleware architecture is a message broker, sometimes called a hub. Each application connects only to the message broker, rather than to other applications. Thus, we have fewer point-to-point links than we would need without the broker. The message broker has two primary functions:
q Routing - to ensure each application receives messages it needs. For example, perhaps both applications A and B should receive a Sales Order if its number begins with a 1, otherwise only application B should receive it. The middleware products support such complex data-based rules.
q Mapping/Transformation - to ensure that the business data contained in the message makes sense to the application. For example, perhaps Sales Order numbers created in application C need to be prefixed with a 6 before being sent to application D. Most middleware products allow any complexity of mapping and transformation, and may often use large database look-up tables.
All messages must be in a format that the receiving application can understand. In order to accomplish this, each application that interfaces with the broker will need an adapter to convert the data format. The adapter normally takes the data in an application specific format, and places it on a queue in a format the message broker can understand. In the reverse direction, the adapter reads the data from the message broker queue and converts it to the application-specific format. There are commercially available adapters for common products, but sometimes we may need to write a custom adapter.
Middleware Design Considerations
Here are some design considerations when building an interface to a middleware system using ALE:
Addition of new applications. A central message broker architecture provides a robust and scalable architecture for distributed systems. This architecture makes it easy to add new applications in the future with minimum work. Since the message broker’s mapping, transformation, and routing abilities are far superior to those of the SAP system, it is easier to reformat data in the broker's adapter and send it to new systems.
Processing time and throughput. There is additional overhead in the message processing time between an application creating the message and an application receiving a message. This can be a serious delay. With complex transformation, database look-ups, and routing rules, it is important to ensure that the middleware architecture can handle the transaction volumes. Similar design considerations when choosing between ALE and ABAP also apply to middleware design. When a high volume system-specific batch interface is required, a point-to-point ABAP may be the best option.
Data transformation. ALE rules provide some degree of data transformation and routing. However, other applications may not have this degree of flexibility, and it may be sensible to contain this information within one system - the message broker -- rather than distribute these rules around the system
Development time. Middleware development time is significant, and we need to take it into account when planning interfaces. It is likely that both ALE and middleware development might be needed, as well as custom programming for the legacy application posting and extraction routines.
Conciseness of specifications. Since field-by-field mappings and transformations are an essential part of a middleware development, the specifications must contain the detailed information required to build the specified interface.
Should we use ALE or ABAP?
Here are some considerations in the decision to use an ALE interface, or to develop an ABAP-based interface:
q Existing interfaces. When an existing interface design is established then it makes sense to maintain the design to minimize the development needed.
q SAP Standard Scenarios. If SAP supplies needed functionality then it makes sense to use it.
o There are many standard upload programs available in SAP. This would suggest an ABAP approach for the interface, since the program already exists and there should be minimum effort to build the interface
o There are many standard ALE scenarios provided in the SAP system. SAP supports these scenarios and enhancement is quick and easy. Where there is a standard ALE scenario for an interface then this suggests that a middleware solution may be best.
q Timing Requirements. Timeliness of data transfer to the sending or receiving application. ALE supports real-time and near-real-time data distribution. A need for immediate transfer suggests a real-time ALE/middleware approach. Periodic processing (once or more per day) suggests a middleware batch processing option, or an ABAP-based interface. Infrequent processing (weekly or monthly) suggests an ABAP batch option.
q Transaction Volume. ALE is usually slower than an ABAP interface. If very high transaction volumes are likely, then ABAP is probably a better choice.
q Number of senders or receivers for common sets of data. When similar data is needed by many receiving systems, or sent by many sending systems, the use of a middleware-based architecture makes more sense, since the message broker can manage the distribution of data to multiple recipients.
q Complexity of SAP processing. In some instances the interface may have to perform multiple transactions in SAP, including controlling the process between these transactions. In these cases an ABAP solution is more appropriate in order to maintain SAP integrity for restart or error management.
q Programmers' Skills. ABAP is generally better understood than ALE, and there are more skilled practitioners.
IDoc Status Codes – Outbound
00 Not used, only R/2
01 IDoc created
02 Error passing data to port
03 Data passed to port OK
04 Error within control information of EDI subsystem
05 Error during translation
06 Translation OK
07 Error during syntax check
08 Syntax check OK
09 Error during interchange handling
10 Interchange handling OK
11 Error during dispatch
12 Dispatch OK
13 Retransmission OK
14 Interchange Acknowledgement positive
15 Interchange Acknowledgement negative
16 Functional Acknowledgement positive
17 Functional Acknowledgement negative
18 Triggering EDI subsystem OK
19 Data transfer for test OK
20 Error triggering EDI subsystem
21 Error passing data for test
22 Dispatch OK, acknowledgement still due
23 Error during retransmission
24 Control information of EDI subsystem OK
25 Processing despite syntax error (outbound)
26 Error during syntax check of IDoc (outbound)
27 Error in dispatch level (ALE service)
28 Not used
29 Error in ALE service
30 IDoc ready for dispatch (ALE service)
31 Error - no further processing
32 IDoc was edited
33 Original of an IDoc which was edited
34 Error in control record of IDoc
35 IDoc reloaded from archive
36 Electronic signature not performed (timeout)
37 IDoc added incorrectly
38 IDoc archived
39 IDoc is in the receiving system (ALE service)
40 Application document not created in receiving system
41 Application document created in receiving system
42 IDoc was created by test transaction
IDoc Status Codes – Inbound
50 IDoc added
51 Error: Application document not posted
52 Application document not fully posted
53 Application document posted
54 Error during formal application check
55 Formal application check OK
56 IDoc with errors added
57 Test IDoc: Error during application check
58 IDoc-Copy from an R/2 connection
59 Not used
60 Error during syntax check of IDoc (inbound)
61 Processing despite syntax error (inbound)
62 IDoc passed to application
63 Error passing IDoc to application
64 IDoc ready to be passed to application
65 Error in ALE service
66 IDoc is waiting for predecessor IDoc (serialization)
67 Not used
68 Error - no further processing
69 IDoc was edited
70 Original of an IDoc which was edited
71 IDoc reloaded from archive
72 Not used, only R/2
73 IDoc archived
74 IDoc was created by test transaction