[Ale sap part 2] Using ALE with Middleware-General Introduction

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 MiddlewareWhat is Middleware?

The wordMiddlewareHas 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 processing 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 isMessage broker,Sometimes calledHub. Each application connects only to the message broker, rather than to other applications. thus, we have fewer point-to-point links than we wowould need without the broker. the message broker has two primary functions:

QRouting-To ensure each application generated es messages it needs. for example, perhaps both applications A and B showould receive a Sales Order if its number begins with a 1, otherwise only application B showould receive it. the middleware products support such complex data-based rules.

QMapping/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 processing application can understand. In order to accomplish this, each application that interfaces with the broker will needAdapterTo 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 too cially 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 processing ing 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 ALEAndMiddleware 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.

 

Shocould we use ALE or ABAP?

Here are some considerations in the demo-to use an ALE interface, or to develop an ABAP-based interface:

QExisting interfaces.When an existing interface design is established then it makes sense to maintain the design to minimize the development needed.

QSAP Standard Scenarios.If SAP supplies needed functionality then it makes sense to use it.

O There are using standard upload programs available in SAP. This wocould suggest an ABAP approach for the interface, since the program already exists and there shocould be minimum effort to build the interface

O There are provided 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.

QTiming Requirements.Timeliness of data transfer to the sending or processing 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.

QTransaction Volume.ALE is usually slower than ABAP interface. If very high transaction volumes are likely, then ABAP is probably a better choice.

QNumber of senders or receivers for common sets of data.When similar data is needed by using messaging systems, or sent by using 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.

QComplexity 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.

QProgrammers '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 completed MED (timeout)

37 IDoc added incorrectly

38 IDoc archived

39 IDoc is in the processing ing system (ALE service)

40 Application document not created in Processing system

41 Application document created in Processing 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