【ALE SAP part 2】Using ALE with Middleware

111

Hi Gurus, I hope that this information will be helpful for you to understand the general idea about SAP ALE middleware. For the detail issue about how to cover the IDoc into the require format document is diff to explain, it's case by case or project by project issue.

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