Note: Provide Connection type as ‘3’ indicating connection to R/3 system
Enter the following details.
Other Useful Link :
Click Here to Read More !!!!
Showing posts with label ALE. Show all posts
Showing posts with label ALE. Show all posts
Friday, April 25, 2008
EDI Configuration : Create RFC Destination Tcode: SM59
Assign Client to the logical system T.code: SALE
Path: ALE--> Basic Settings à Logical Systems à Assign client to Logical System
Other Useful Link :
Click Here to Read More !!!!
Tuesday, July 17, 2007
Useful Guide to ALE, IDOCs
ALE/IDOC
IDOC Programming
There are two processes in IDOC processing one is INBOUND PROCESS( IDOC coming to the system and its handling at various stages) and the other is OUTBOUND PROCESS( IDOC is send to other system . Separate ABAP programs are written for these 2 processes and different configuration settings are required for each one .Depending upon the trigeering mechanism different programming approaches are used.OUTBOUND PROGRAMS handle the IDOC creation and INBOUND PROGRAMS handle the inbound IDOC and the data trasfer from the IDOC to the database tables.
NEED FOR ABAP PROGRAMMING arises if
1)New IDOC was created
Depending upon the triggering mechanism i.e change pointer,message control
etc the programming technique changes and the type of process.
2)Existing IDOC was extended
User Exits are used to populate data in new segments added and to read them
back.
3)To enhance an exsiting process.
User Exits are used .
Basic structure of an OUTBOUND PROGRAM
The basic structure of all outbound programs is same. The CONTROL
record which is of TYPE EDIDC has to be filled. It contains important fields like
IDOCTP IDOC type
MESTYP Message Type
RCVPRN Recieving Partner (Destination)
RCVPRT Partner Type (it is LS i.e Logical System)
The DATA RECORD internal table which is of TYPE EDIDD has to be filled
in the same order as there are segments in the IDOC definition.
It has 2 important fields which are to be filled ,these are
SEGNAM Name of the segment
SEGDATA Data in the segment and can be upto 1000 bytes.This field
is corresponds to each data segment in the IDOC.
e.g.
DATA INT_EDIDD LIKE EDIDD OCCURS 0 WITH HEADER LINE.
DATA W_SEGDATA LIKE zsegment "custom segment zsegment
INT_EDIDD-SEGNAM = 'ZSEGMENT'
W_SEGDATA-field1 = value "taken from some table
W_SEGDATA-field2 = value "taken from some table
INT_EDIDD-SEGDATA = W_SEGDATA
APPEND INT_EDIDD
This will fill the data record corresponding to the segment ZSEGMENT . For all
segments the sam steps will be repeated until all the data corresponding to all the
segments in the idoc is filled in the internal table of type EDIDD.
There is only one control record and can be multile data records in the idoc
structure.
Which data is to be extracted from the tables to be filled in EDIDD type internal table is determined in standalone programs from the objects which are specified in the selection screen and from the object key passed to the function module in case of message control and is taken from BDCP table in case of change pointers using function modules "CHANGE_POINTERS_READ"
In case of stand alone programs and function modules based on change pointers method the function module "MASTER_IDOC_DISTRIBUTE" is used to send the IDOC to ALE layer for distribution ,in case of message control it is handled automatically by the RSNASTED program invoked by the message control.
OUTBOUND PROCESS AND OUTBOUND PROGRAM.
Outbound programs are used in outbound process to genearte IDOCs . There
purpose is to extract the data from the tables and to fill the IDOC data records
and the control record in the IDOC and pass ito the ALE layer for distribution to the recieving system .
Depending upon the triggering mechanism (how and when the outbound program will be started different techniques and interface is used for outbound program.
1)Message control
Application like PO(purchase order) creation use this technique , where the output type is linked to the application(Message control is a configurable cross application component which can be set in IMG .Such programs are created in the form of function modules and linked to the output type which is linked to the apllication.These have predefined interfaces.
In outbound programs(function module) that use message control the key of the
application document is passed to the function module whcig will read the data from the table depending upon the key passed(NAST structure) and fill the IDOC segemnts with the application data.The control record is also passed to the function module but is not fully filled, the rmaining fields are filled and the control is passed back to the calling program which is RSNASTED and is invoked by the
message control to process ALE and EDI output types and this program on recieving the IDOC data will create the physical IDOC in the system.
The parameteers passed to the function module are
IMPORTING PARAMETERS
OBJECT LIKE NAST
It contains documents key.
CONTROL_RECORD_IN LIKE EDIDC
It contains the partailly filled control record
EXPORETING PARAMETER
OBJECT_TYPE
CONTROL_RECORD_OUT LIKE EDIDC
TABLES
INT_EDID LIKE EDIDD
The internal table used to fill the data records in the same order as they exists in the IDOC.
The important parameters that should be filled in the custom function module are
CONTROL_RECORD_OUT and INT_EDIDD .The OBJK field of the structue NAST contains the key of the apllication document.
2)Stand alone programs
Generally used for Master Data transfer and as such depending upon the requirement can have different interfaces.The programs have a selection screen which has select options to select the objects, and parameters for specifying the recipient Logical System and the Message Type.
Data is selected based on the specified objects from the tables . and control record of type EDIDC is created and filled with important values like DIRECTION ,IDOCTP,RCVPRT,RCVPRN and MESTYP .
Data is filled in an internal table of TYPE EDIDD according to segment definitions
and in same order and the function module MASTER_IDOC_DISTRIBUTE is called passing the control record and the internal table containg IDOC data and importing an internal table consisting of control records for each communication IDOCS created.
3)Change pointer
Change Pointer table is read and checked if changes were made to important fields , if so the outbound program will be triggered automatically , these have predefined interfaces
ALE/IDOC Transaction
SALE Area Menu for ALE configurations.It includes transactions for
Logical System definition and linking it to a client, Transactions for
RFC Destination and Port Definition Etc.
SM59 RFC Destination
Here we specify the login settings for the destination including
the I.P address or Application Server name and the User name and
password.The information entered here is used to run Remote Function
Calls(RFC ) on the destination server .We can create number of types
of RFC Destinations but 3 types are important .
R/3 (R/3 to R/3), LS(logical system) and TCP/IP.
The name of the RFC destination should be same as that of Logical
System as it helps in creation of automatic partner profiles.
WE21 Port Definition.
There are 6 types of ports but only 2 types File and Transactional RFC
types of ports are important.
We have to specify the RFC Destination before a port can be created.
WE57 This is used to assign the Inbound function module to the Message Type
and to the IDOC Type.
WE42 This is used to define the process Code for Inbound Processing.
BD95 Define Filter object type .We can specify the field and the table it belongs
to as a filter object .
BD59 Assignment of Filter object type to the Message Type .Here we create the
link between Filter object and the segment and the message type and the
segment Field.
BD50 Set message Type to reducible.
BD65 Define Mandatory Fields.
BD64 Distribution Model . Also known as Customer Distribution Model Used to
define all the messages that will be exchanged between remote systems
and the name of thes logical systems. Any filters can also be specified.
The model once created has to be distributed on every system which will
be communicating ,It can be maintained on only One system.
BD21 Creating IDOcs from change pointers.
This can be used to create IDOCs from change pointers for a particular
message LIKE MATMAS.
BD22 This can be used to delete change pointers.
BD87 Status Monitor. Idocs can be selected base on number of criteria and there
processing status can be seen in detail.
BD10 Material Master Data Distribution .
Based on Message MATMAS.
BD12 Customer Master Data Distribution .
Based on Message CREMAS.
BD14 Vendor Master Data Distribution
Based on Message DEBMAS .
BDFG Generate ALE Interface for BAPI.
Here we specify the Business Object and the BAPI Function module for
which the interface has to be created.
WE31 Segment Editor.
This is used to create segments. We create the segment type and
segment definition is automatically created by editor e.g. Z1DUMMY is
segment type and Z2DUMMY is the segment definition .We specify the
fields and the data elements these cp\orresponds to create segments.
WE30 IDOC Editor
It is used to create a new IDOC Type or IDOC Extension .We specify the
segments that will be addd to the IDOC type.
WE02/05 IDOC List.
Various selct options and parameters are provided to select IDOCs
depending on the date, direction , mesage type etc.
WE20 Partner Profile
Here we create partner profile for each and every partner from / to which
the messages will be exchanged.There are 6 types of PF generally only
profiles of type LS(Logical System) ,KU(Customer) ,LI(Vendor) is used.
We specify the partner number and partner type and the agent and
the agent type responsible for handling of errors .
For every message send to the partner we have a outbound record and for
evry message coming from the partner we have the inbound record .
We specify the message in the otbound/inbound records ,double
clicking will take us to the detailed screen where the IDOC Type ,Port
and whether the IDCO will be immediatelt processed or collected are
mentioned.
IDOC Status Code
Status Description
00 Not used, only R/2
01 IDoc generated
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 target system (ALE service)
40 Application document not created in target system
41 Application document created in target system
42 IDoc was created by test transaction
50 IDoc added
51 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 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 transferred 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
IDOC Function
CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
EXPORTING
VALUE(MASTER_IDOC_CONTROL) LIKE EDIDC STRUCTURE EDIDC
" Control record of master IDoc
VALUE(OBJ_TYPE) LIKE SERIAL-OBJ_TYPE DEFAULT ''
VALUE(CHNUM) LIKE SERIAL-CHNUM DEFAULT ''
TABLES
COMMUNICATION_IDOC_CONTROL STRUCTURE EDIDC
" Control records of created comm. IDocs
MASTER_IDOC_DATA STRUCTURE EDIDD
" Data records of master IDoc
EXCEPTIONS
ERROR_IN_IDOC_CONTROL
" Incorrect entry in IDoc control record
ERROR_WRITING_IDOC_STATUS
" Error when writing IDoc status records
ERROR_IN_IDOC_DATA
" Incorrect entry in IDoc data records
SENDING_LOGICAL_SYSTEM_UNKNOWN
" Own logical system unknown
CALL FUNCTION 'CHANGE_POINTERS_READ'
EXPPORTING
VALUE(ACTIVATION_DATE_HIGH) LIKE SY-DATUM DEFAULT SPACE
VALUE(ACTIVATION_DATE_LOW) LIKE SY-DATUM DEFAULT SPACE
VALUE(ACTIVATION_TIME_HIGH) LIKE SY-UZEIT DEFAULT '000000'
VALUE(ACTIVATION_TIME_LOW) LIKE SY-UZEIT DEFAULT '000000'
VALUE(CHANGE_DOCUMENT_OBJECT_CLASS) LIKE CDPOS-OBJECTCLAS
DEFAULT SPACE
VALUE(CREATION_DATE_HIGH) LIKE SY-DATUM DEFAULT SPACE
VALUE(CREATION_DATE_LOW) LIKE SY-DATUM DEFAULT SPACE
VALUE(CREATION_TIME_HIGH) LIKE SY-UZEIT DEFAULT '000000'
VALUE(CREATION_TIME_LOW) LIKE SY-UZEIT DEFAULT '000000'
VALUE(MESSAGE_TYPE) LIKE BDCPS-MESTYPE
VALUE(READ_NOT_PROCESSED_POINTERS) LIKE BDCPS-PROCESS DEFAULT
'X'
TABLES
CHANGE_POINTERS STRUCTURE BDCP
MESSAGE_TYPES STRUCTURE BDMSGTYP OPTIONAL
EXCEPTIONS
ERROR_IN_DATE_INTERVAL
ERROR_IN_TIME_INTERVAL
CALL FUNCTION change_pointers_status_write.
IMPORTING
VALUE(MESSAGE_TYPE) LIKE EDIDC-MESTYP
TABLES
CHANGE_POINTERS_IDENTS STRUCTURE BDICPIDENT
Examples of Inbound function modules are
IDOC_INPUT_BLAOCH IDoc inbound processing: change Ccontract
IDOC_INPUT_BLAORD IDoc inbound processing: Create Contract
IDOC_INPUT_MATMAS01 IDoc inbound processing: Material Master
Examples of Outbound function modules are
IDOC_OUTPUT_BLAOCH
IDOC_OUTPUT_BLAORD
Other USeful Links :
Download IDOC Presentation
Click Here to Read More !!!!
Sunday, June 10, 2007
ALE Performance
By: Thomas Nittmann and Tim Yates, DataXstream www.dataxstream.com
There are a variety of options one can utilize in order to optimize the use of Application Link Enabling. Following these guidelines will help you make the most of ALE.
1.Watch out for Interference with Other Interfaces and System Load.
Many different application areas leverage ALE technology and understanding their impact on each other is important. The impact of interfaces interacting and creating performance issues is typically not found until production problems arise. Coordinated scheduling of interfaces is also very important. Other system load conditions can significantly impact ALE performance. Logon groups and dedicated ALE application servers can significantly reduce the effects.
2. Archiving: For the purposes of this tip we will refer to IDOCs, Workflow, Change Points, and Message Control for archiving. The use of ALE technologies is abundant in many applications. This can significantly impact system performance as buffer tables and their indices grow. Scheduling appropriate maintenance jobs is important in maintaining system performance in interfaces. While performance is not an issue in development and test environments, space usually is. Make sure your archiving plan is comprehensive. Also ensure that your archiving criteria are appropriate for the specific situation
3.Be cognizant of inefficient User Exit code. Interface User Exits and Application Exits can significantly impact ALE performance. Inefficient User Exit Code can decrease IDOC processing performance by more than 10-fold. Efficient ABAP Code is important when large volumes of IDOCs are being processed. Also make sure that User Exit Code is being implemented in the most effective exit. It is possible that the same operation can be implemented more efficiently in another exit.
4. Watch Workflow Error Handling. SAP ALE error handling is managed by SAP Workflow. Running Transaction BD72 generates initial Workflow event linkages for all ALE Message Types. This linkage routes all errors to specified users' inboxes. Workflow processing creates overhead in the system. If you are not using workflow to manage IDOC errors, turn it off. This will reduce system load when IDOC errors occur and will reduce disk usage by interfaces.
5. Make sure the Automatic tRFC Batch Retry is switched ON. The tRFC Batch Retry Flag is defaulted ON when an RFC Destination is created. When a communication error occurs, the tRFC Batch schedules a Retry Job in the background, with a frequency of every 2 minutes. If you were sending 1000 IDOCs with a packet size of 10, that would result in the 100 background jobs executing every 2 minutes. This will result in ALE taking down the SAP batch job scheduler.
Other Useful Link :
What is ALE?
How ALE Works?
ALE Converters
ALE Message Handler
Click Here to Read More !!!!
ALE Message Handler
An ALE Message Handler acts as a bridge between SAP R/3 and another application or multiple other applications. It receives intermediate documents (IDocs) from one or more instances of SAP R/3 and carries them to application(s) for processing. Likewise, it sends IDocs received from applications to one or more SAP R/3 instances.
In contrast to an ALE converter, the message handler will not do any conversion or mapping but instead deliver IDocs without changing them. It is assumed that a message handler has some sort of queuing mechanism and guarantees reliable delivery.
The following SAP CSP members have certified products handling messaging:
- BEA Systems [BEA eLink for R/3]
- Compaq Computer [Compaq BusinessBus]
- Hitachi [Message Queue -Access]
- IBM (UK) [MQSeries for R/3]
- Kaba Benzing [B-COMM for R/3 ERP]
- NEON New Era of Networks [NEONadapter]
- TIBCO Software [TIB/AcitveEnterprise]
- TSI International [Mercator]
- Viewlocity [AMTrix System]
Other Useful Link :
What is ALE?
How ALE Works?
ALE Converters
ALE Converters
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 following converter functions are covered by SAP CA-ALE certification <ALE Converters>
They have the following properties:
-the transfer of R/3 intermediate document (IDoc) formats straight into their own repository so that these data descriptions can be used as source or target structures when assigning data fields.
-adoption and conversion of intermediate documents from R/3 Systems via the ALE interface - a remote function call that can be called up using a normal transaction.
-conversion of any data format into intermediate document structures and import into the R/3 System via a remote function call (RFC) in the ALE interface.
ALE converters enhance the concept of EDI subsystem interfaces by:
-using direct program-to-program communication instead of a file interface to transfer IDocs
-recognizing the format of any interface structure of a non-SAP system and not just standard EDIFACT or ANSI-X12 formats.
Other Useful Link :
What is ALE?
How ALE Works?
ALE Message Handler
Click Here to Read More !!!!
How ALE Works?
ALE allows the user to perform an SAP transaction in the sending system, after which the following steps occur:
1. 1 or more communication IDocs (intermediate documents: container for the application data) are created in the sending system database. An ALE distribution model, that needs to have been configured, determines which systems the IDocs are to be sent
2.These communication IDocs, that contain the relevant application data of the transaction that was performed, are then passed to the ALE communication layer
3. This layer performs an RFC call using the port definition and RFC destination determined through the customer model
4. The IDocs are then transferred to the respective receiving systems. These could be SAP R/3, R/2 or external systems
5. If the receiving system is an SAP system then:
-In the case of master data distribution the same transaction that was performed on the sending system is again performed on the receiving system with the data contained in the IDoc. This allows the data to go through the SAP checks before posting occurs
-In the case of transaction scenarios the relevant data is passed to the respective transactions in order to load the required application document. E.g.. A PO is loaded on the sending side, yet a SO is created on the receiving system
6. Master data has another difference:
-It can be set up in such a way that any changes made to specific fields in master data tables can automatically trigger off the ALE distribution process for that particular master data object
-If a master data object is created or changed on a sending system and distributed to another system the respective transaction is used to either create or change that respective master data object on the receiving system
In general, if standard SAP can't perform the task required then neither can ALE. It doesn't add functionality, it merely decouples it and allows you to distribute it onto other remote systems.
The Detail as described by SAP
In the output processing one of the function modules of the application creates an IDoc, the so-called master IDoc. This IDoc is sent to the ALE layer where the following processing steps are applied:
Outbound processing
Receiver determination
An IDoc is similar to a normal letter in that it has a sender and a receiver. If the receiver has not been explicitly identified by the application, then the ALE layer uses the customer distribution model to help determine the receivers for the message.
The ALE layer can find out from the model whether any distributed systems should receive the message and, if so, then how many. The result may be that one, several or no receivers at all are found.
For each of the distributed systems that have been ascertained to be receiver systems, the data that is specified by the filter objects in the customer distribution model is selected from the master IDoc. This data is then used to fill an IDoc, and the appropriate system is entered as receiver.
Data selection
Segment filtering
Individual segments can be deleted from the IDoc before dispatch by selecting Functions for the IDoc processing -> Settings for filtering in ALE Customizing. The appropriate setting depends on the sending and receiving logical R/3 System.
Field conversion
Receiver-specific field conversions are defined under Functions for the IDoc processing -> Conversions.
General rules can be specified for field conversions; these are important for converting data fields to exchange information between R/2 and R/3 Systems. For example, the field "plant" can be converted from a 2-character field to a 4-character field.
The conversion is done using general EIS conversion tools (Executive Information System).
Version change
SAP ensures that ALE functions between different R/3 System releases. By changing the IDoc format you can convert message types of different R/3 releases. SAP Development use the following rules when converting existing message types:
-Fields may be appended to a segment type;
-Segments can be added;
ALE Customizing keeps a record of which version of each message type is in use for each receiver. The correct version of the communication IDoc is created in the ALE output.
The resulting IDocs (it is possible that several IDocs could be created in the receiver determination) are referred to as communication IDocs and are stored in the database. The dispatch control then decides which of these IDocs should be sent immediately. These are passed to the communications layer and are sent either using the transactional Remote Function Call (RFC) or via file interfaces (e.g. for EDI).
If an error occurs in the ALE layer, the IDoc containing the error is stored and a workflow is created. The ALE administrator can use this workflow to process the error.
Inbound processing
After an IDoc has been successfully transmitted to another system, inbound processing is carried out in the receiver system, involving the following steps in the ALE layer:
Segment filtering
Segment filtering functions the same way in inbound processing as in outbound processing.
Field conversion
Specific field conversions are defined in ALE Customizing.
The conversion itself is performed using general conversion tools from the EIS area (Executive Information System).
Generalized rules can be defined. The ALE implementation guide describes how the conversion rules can be specified.
One set of rules is created for each IDoc segment and rules are defined for each segment field.
The rules for converting data fields from an R/2-specific format to an R/3 format can be defined in this way. An example of this R/2 - R/3 conversion is the conversion of the plant field from a 2 character field to a 4 character field.
Data transfer to the application
Input control
When the IDocs have been written to the database, they can be imported by the receiver application.
IDocs can be passed to the application either immediately on arrival or can follow in batch.
You can post an inbound IDoc in three ways:
1. by calling a function module directly: A function is called that imports the IDoc directly. An error workflow will be started only if an error occurs.
2. by starting a SAP Business Workflow. A workflow is the sequence of steps to post an IDoc.
3. by starting a work item A single step performs the IDoc posting.
The standard inbound processing setting is that ALE calls a function module directly. For information about SAP Business Workflow alternatives refer to the online help for ALE programming.
Other Useful Link :
What is ALE?
ALE Converters
ALE Message Handler
What is ALE?
ALE is a business solution to a very real need emerging in the SAP market. This is the need for businesses to move towards tighter integration between systems, yet, at the same time, provide independence to the various business units within the company.
In the past the move was towards centralized systems...
Standardization of business processes accompanied by ever tighter integration within the central system no longer represents a practicable approach to this problem. The following are some of the most commonly encountered difficulties:
-technical bottlenecks,
-upgrade problems,
-the effect of time zones on international corporations,
-excessively long response times in large centralized systems.
How do you achieve this "loosely coupled applications" without compromising data integrity, without committing yourself to a specific technology, without adding to the technical issues mentioned above, ???
What if you want to link in to external systems as seamlessly as possible?
The SAP Solution - ALE
SAP has provided ALE (Application Link Enabling) as the solution to these issues. It allows you to:
-distribute your applications across several SAP systems, such that centralized functions, as well as decentralized functions can operate in the same company arena
-maintain and distribute master data elements from a central system, thus maintaining unique number ranges across several systems
-maintain and distribute control data objects from a central system, thus synchronizing important configuration data. This is important when trying to decentralise functions, yet keep them integrated
-couple R/2 and R/3 systems, in some instances
-couple SAP and external systems, via IDocs (Intermediate documents) and an external translation mechanism
ALE also provides you with tools that allow you to:
-manage the ALE process seamlessly. These tools include the reprocessing of communication errors, business process and technical error handling and routing via workflow, archiving of data
-keep audit trails of all the ALE communication
-configure the ALE solution in many different ways in order to tailor make a solution for the user
In SAP's words:
"The ALE (Application Link Enabling) concept available in R/3 Release 3.0 supports the construction and operation of distributed applications. It incorporates the controlled exchange of business data messages whilst ensuring data consistency across loosely coupled SAP applications. The integration of various applications is achieved by using synchronous and asynchronous communication, rather than by means of a central database.
ALE comprises three layers:
-the applications services,
-the distribution services,
-the communications services.
In order both to meet the requirements of today's customers and to be open for future developments, ALE must meet the following challenges:
-Communication between different software releases.
-Continued data exchange after a release upgrade without special maintenance.
-Independence of the technical format of a message from its contents.
-Extensions that can be made easily, even by customers.
-Applications that are decoupled from the communication.
-Communications interfaces that allow connections to third-party applications.
-Support for R/3-R/2 scenarios.
Other Useful Link :
How ALE Works?
ALE Converters
ALE Message Handler
Monday, June 4, 2007
Thursday, May 31, 2007
Wednesday, May 30, 2007
Subscribe to:
Posts (Atom)