Message Control is a mechanism by which documents are output based on certain conditions. In ALE scenarios this is basically used to transfer transaction data (fulfilling configuration settings defined in message control) from one system to another. For eg. we want to send purchase order IDocs from customer to vendor system using ALE. On saving of purchase order the IDocs should be triggered. Further the IDocs should only be sent when the purchasing document fulfils certain conditions - purchase document of a certain document type only needs to be sent. By output control we can configure the conditions and the timing (when the document should be triggered) and using ALE (as interfacing technology) we can send IDocs (containing application data fulfilling conditions) from one system to another. Important transactions: NACE - Configuring Message Control setting corresponding to various applications. NACO - Configuring Message Control setting corresponding to various applications. WE81 - Defining new message types. WE82 - Linking the message type with the basic IDoc type. WE20 - Partner Profile settings. WE21 - Port Definition SM59 - RFC Destination
1) The application id, communication structure and o/p determination procedure are responsible for triggering IDocs corresponding to a particular application document. For this to happen message control settings have to be done.
2) Message Control – also referred to as output control or conditioning technique – is a cross-application component used as a service program in several areas. The basic concept behind Message control is to generate and manage outputs from an application and control their timings and medium of exchange.
3) Message control settings can be done via transaction NACE or via transaction NACO.
4) Starting point in message control in the “Output Determination Procedure” (Procedure within NACE txn.). Depending upon the configuration setting in SPRO this procedure is determined. A procedure defines a set of possible outputs for an application. We can define several procedures for an application, but only one can be configured as active (i.e. for a particular transaction document within an application only one procedure will be determined based on configuration settings). Eg->
a) For Delivery (txn. VL01NO) the document type setting in configuration (SPRO -> Logistics Execution -> Shipping -> Deliveries -> Define Delivery types) determines the procedure. So whenever we save a document of particular application (of particular application id) and of particular document type, the particular o/p determination procedure is triggered.
b) For sales, SPRO -> Sales and Distribution -> Basic Functions -> Output Control -> Output Determination -> Output Determination Using the Condition Technique.
5) In the transaction NACE we can see that corresponding to application id (say ‘V2’ (shipping)) various procedures are defined:
On navigating the procedure we find a list of o/p types for application ‘V2’.
6) Before making the entry of the output type corresponding to a particular procedure, we have to define it with its attributes. The output type defines the characteristics and attributes of the output itself. We can access the output types on transaction NACE by selecting an application and clicking the Output type button.
Double clicking an output type will lead to its details:
7) Access sequence defines a sequence in which business rules are checked for proposing an output type. It has following attributes:
- A set of business rules or conditions.
- A sequence in which the rules or conditions are checked.
- A requirement that checks for business rules using ABAP programs.
- An exclusive or inclusive strategy. We can access the access sequences on transaction NACE by selecting an application and clicking the Access Sequences button.
To view the details of an access sequence, select it and then double click on the Accesses folder in the Dialog structure frame.
Business rule 1 is based on SOrg./Distrib.Ch/Division/Customer. Business rule 2 is based on Sales Organization/Customer Number. Each business rule is, effectively, a set of fields defined in a condition table.
😎 Condition table specifies the key fields for a business rule. Hence for Business rule 1 the key is Sales Org., Distribution Channel, Division and Customer.
9) Condition records are inserted in the condition table. The transaction is evaluated with the key (of the condition table based on business rule) and if the transactional data matches with the condition record the output is proposed. Condition records are defined at last.
10) Several programs and tables are part of Message Control. For EDI, the following tables and programs will frequently be dealt with:
*NAST - This table has an entry for the processing program used for an output type.
*TNAPR - This table has an entry for the processing program used for an output type.
*RSNAST00 - This program is used to process entries in the NAST table.
*RSNASTED - This processing program exists for each output medium. ALE_PROCESSING is the routine in the RSNASTED program to process ALE outputs.
11) Final overview of the components used in Message control to propose outputs.
12) After doing all the settings for message control, the partner profile setting for this ALE scenario needs to be accomplished. We need to add the following entry to the outbound parameters of the partner profile:
13) One important question that arises at this juncture is, how is the partner profile determined from the output type is case of ALE? This is information is stored in table EDP12 (Partner Profile: Outbound with Message Control). Based on the Partner type of receiver (RCVPRT), output type (KSCHL) and Application for message conditions - without value table (KAPPL), the Partner number of receiver (RCVPRN), Outbound process code(EVCODA), Message type (MESTYP) and other related values are determined.
2 Comments
