Interface programming [REV]
- via File interface (Dateischnittstelle)
- via Remote Function Call (RFC)
- Business Application Programming Interface (BAPI)
- Application Link Enabling (ALE)
- IDocs
- SOAP
- OData
- ABAP channels
- bgRFC Programming
- Information (22.09.2021)
- 1793313 - ALE: IDoc inbound processing using bgRFC as standard
- 2183108 - t/qRFC processing: general performance verifications
via File interface (Dateischnittstelle)
- Call-Transaction-Program
- Methods of the global class CL_GUI_FRONTEND_SERVICES are available for files on presentation servers.
- Batch-Input
- Direct Input
via Remote Function Call (RFC) is the SAP interface technology allowing to call a function in another system or internally
- Authorizations for RFC
- Monitoring und Troubleshooting
- Monitoring the output queue:
- SMQ1 for monitoring the outgoing queues
- Use transaction SBGRFCMON to track how your bgRFC inbound bgRFC monitor calls are processed.
- RFC Destinations
- Connection type 3: The target system is an SAP system
- Connection type T: The target system is an external system.
- RFC Types
- Synchronous RFC (sRFC) for reading
- Call function 'ABC' destination P_DEST
- P_DEST: None (local), space, back
- After each CALL FUNCTION, the calling system implicitly executes
Commit to the database. - ( use tRFC ) Synchronous RFC (sRFC) to create, change, delete
- X parameter with Change code
- Exclusive Write lock (Enqueue/ Dequeue)
- CALL FUNCTION 'ABC' IN UPDATE TASK
- COMMIT WORK/ ROLLBACK WORK
- Asynchronous RFC (aRFC) for load distribution
- Asynchronous RFC (aRFC) is used to distribute tasks to several SAP systems. You can use the addition STARTING NEW TASK t to call a function modulecan be started asynchronously on another system.
- Transactional RFC (tRFC) for writing
- If the target system cannot be reached, a job can be created automatically,
that repeats the call with the same transaction ID. - If the remote function module terminates with an error, the target system
automatically selects the ROLLBACK WORK command. - CALL FUNCTION 'ABC' IN BACKGROUND TASK DESTINATION p_dest
- Logical Units of Work that were created using tRFC are stored in the target system are executed independently of each other.
- Queued RFC (qRFC)
- qRFC with outbound queue: in this scenario, the sending system uses an outbound queue (Outbound Queue) to ensure the serialization of the data and the called function modules are stored in the outbound queue
of the sending system. - Initialize qRFC: CALL FUNCTION 'TRFC_QUEUE_INITIALIZE'.
& CALL FUNCTION 'TRFC_SET_QUEUE_NAME' - CALL FUNCTION 'ABC' IN BACKGROUND TASK DESTINATION p_dest
- qRFC with outbound and inbound queue: even if the receiving system has an input queue there is always an output queue in the sending system,
because this is used to serialize the calls. The input queue in the receiving system, however, separates the Transmission of the calls from their processing. - Initialize qRFC: CALL FUNCTION 'TRFC_QUEUE_INITIALIZE'.
- Set properties of the input queue: CALL FUNCTION 'TRFC_SET_QIN_PROPERTIES'
- Call function: CALL FUNCTION 'ABC' IN BACKGROUND TASKDESTINATION p_dest
- Background RFC (bgRFC)
- Additional configuration is required (T-code SBGRFCCONF)
- SAP recommends that for new applications to use the bgRFC replacing tRFC and qRFC.
- Outbound: tRFC, qRFC
- Inbound is only used for load distribution within
of a system and replaces the aRFC. - Create a destination object:
- TRY.
lv_dest_name = p_dest.
destination = cl_bgrfc_destination_outbound=>create( dest_name ).
CATCH cx_bgrfc_invalid_destination.
ENDTRY. - Create a unit object and assign the unit object to a queue if necessary:
- unit = destination->create_qrfc_unit( ).
TRY.
unit->add_queue_name_outbound( 'QUE' ).
CATCH cx_qrfc_duplicate_queue_name.
ENDTRY. - Call the function modules:
- CALL FUNCTION 'ABC' IN BACKGROUND UNIT unit
- Complete the LUW: COMMIT WORK.
Business Application Programming Interface (BAPI)
- Define business object types with transaction SWO1
- Business object consists of five components (Interfaces,Key fields,Attributes, Methods and Events)
Application Link Enabling (ALE)
- Main tables: EDIDC, EDIDS, EDIDD
- Create an IDoc structure
- Create a segment, WE31
- Create an IDoc type (IDoc-Typen)
- Create a message type (Nachrichtentyp), WE81/WE82
- A program to send an IDoc:
- Check whether receivers exist at all: CALL FUNCTION 'ALE_MODEL_INFO_GET'
- Generate an IDoc: CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE'
- A FM to process: Z_IDOC * (sample from FM ALE_INPUT_ALEAUD)
IDocs
SOAP
Introduction to Service Development
A service provides a solution for predefined tasks and is implemented in a system.- The service is provided by a provider and is implemented in a provider system.
- The service is in turn consumed by a consumer in a consumer system.
Apart from the technical implementation, there are also many questions and requirements surrounding the development of services. Here are some examples to illustrate this:
- Where is the service provided and where is it required?
- Does the service already exist or does it need to be developed first?
- What kind of character does the service have? Is it a company-internal service (A2A) or a cross-company service (B2B)? Is the service essential for the execution of the overall process or is it an isolated service?
- Is it a finely-granulated service, or does it comprise other services?
- How many consumers will access the service? Is the execution time of critical importance in the scenario?
- Does the service data need to be displayed on the user interface?
SAP NetWeaver uses XML technology for the service descriptions. Since in the outside-in approach you create non-language-specific service descriptions and not classic development objects, this phase is known as the design phase.
Development Approaches
- Point-to-Point:
- Inside-Out: You create a WSDL document for an existing function in the application system (that you can then publish on a UDDI server, for example). The caller generates a consumer proxy from the WSDL document; the application on the consumer side then uses this proxy to call the service at the provider.
- Outside-In:
- Development begins in the Enterprise Services Repository with the design of service interfaces which can be called directly as a WSDL document. Based on the service interfaces, developers generate proxies for both the provider and the consumer
- However, the WSDL document does not contain any information about how the provider of the service can be addressed. Which method is used to complete this information depends on the development variant (point-to-point or using the Integration Server).
- Integration Server
- Outside-In
- Inside-Out: You import an XML description for an existing function to the Enterprise Services Repository. The XML description can be used by any number of callers for communication using the Integration Server
Types of Message Transmission
- Synchronous
- Asynchronous
- Proxy objects (for example, classes, methods, and data types).
- A service definition for communication using the Web service runtime.
Creating and Configuring Service Providers and Service Consumers
If the AS ABAP functions as a service provider, a service interface is created for the implemented function. This represents the Web service for the user. Based on this interface, the service is configured and can be called at runtime.
- Using the Enterprise Services Repository (outside-in)
- Model a service interface in the Enterprise Services Repository.
- Using Metadata Repository ( It allows you to model data types, message types, and service interfaces directly in the ABAP development environment. MDR is the Web service modeling environment in ABAP development landscapes.)
- Based on existing functions (inside-out)
#Consuming a Web Service
If the AS ABAP has the function of a service consumer, it is possible to generate a proxy - in just a few steps - using a WSDL document. The service can be called from a program.
You assign each service interface an interface pattern, which describes the type of the communication to be executed.
Fault message types are designed for application-specific errors that occur at the provider (inbound side) and that are reported back to the sender or persisted in monitoring. In the synchronous case, when an application-specific error occurs on the inbound side, instead of sending a response message back to the sender, the application can send a fault message to handle the error.
When a proxy is generated from a message interface, an exception class is generated for a fault message type. You use this exception class to handle application errors at runtime (also see the example below).
In ES Repository, Data Type is an object, containing the structure of data that defines the message. You use these messages when there is an exchange of data during web service communication (point-to-point) or in Integration Server communication. You define a data type using XML Schema Definition Language (XSDL).
Other
- Inside-Out-Webservices und -Webclients mit dem AS ABAP
- ABAP-SOAP-Webservice
- Create SE80
- Service-Provider (Webservice)
- Choose: Backend, Enterprise Services Repository, Vorhandenes ABAP-Objekt (Inside Out) und Externe(s) WSDL/Schema
- ZIFP_XXX_SERVICE
- Funktionsgruppe, Funktionsbaustein und BAPI
- Choose operations: + Commit, Rollback
- Configuration: Rights
- SOAMANAGER
- Service- und Binding-Namen
- Provider-Sicherheit
- SOAP-Protokoll
- WSDL generation
- Definition of the simple and complex data types
- Description of the message types
- Description of operations
- Binding style and SOAP action
- Servicename und URL
- Testing
- SOAP request, enveope
- Header
- Body
- </SOAP-ENV:Header>
- <SOAP-ENV:Body>
- <ns1:OrderGetlist xmlns:ns1='urn:sap...'>
- <ImRefid></ImRefid>
- </ns1:OrderGetlist>
- </SOAP-ENV:Body>
- </SOAP-ENV:Envelope>
- SOAP-Response
- ABAP-SOAP-Webclient
- SE80
- Service-Consumer
- WSDL/Schema
- Externe(s) WSDL/Schema
- Generate proxy class
- SOAMANAGER
- Name des logischen Ports
- WSDL-Informationen
- Binding-Auswahl
- Consumer-Sicherheit
- HTTP-Einstellungen
- SOAP-Protokoll
- Identifiable Business Context
- Program to call the service
- DATA:
- r_proxy TYPE REF TO zifp_co_zifp_order_service,
- output TYPE zifp_order_getlist_response,
- input TYPE zifp_order_getlist,
- wa TYPE zifp_zifporder.
- TRY.
- CREATE OBJECT r_proxy
- CATCH cx_ai_system_fault.
- ENDTRY.
- TRY.
- CALL METHOD r_proxy->order_getlist
- EXPORTING
- input = input
- IMPORTING
- output = output.
- CATCH cx_ai_system_fault.
- CATCH cx_ai_application_fault.
- ENDTRY.
- LOOP AT output-ta_orders-item INTO wa.
- WRITE:/ wa-orderid, wa-type, wa-refid,
- wa-buyer, wa-seller, wa-orderdate.
- ENDLOOP.
- Outside-In-Webservices und-Webclients mit dem AS ABAP
- System Landscape Directory
- If you have a connection to an Enterprise Services Repository 7.1 or you have received services through an Enhancement Package that were modeled in the ES Repository, you can call these from your programs in the ABAP back end.
- Backend Repository
- SPXNGENAPPL
- Webservices und Webclients mit dem AS Java
OData
- SAP Gateway ( a component of a Business suite )
- Embedded Deployment
- Central Hub Deployment
- OData-Protokoll
- OData-Services entwickeln
- It consists of five components: Model-Provider-Klasse, Data-Provider-Klasse, Technisches Modell, Technischer Service, OData-Service
- Start T-code: SEGW, create a Project
- Data model: entity types, associations, entity sets, Function Imports
- Generation of the components and creation of the OData service
- Monitoring und Fehlersuche
- OData-Services mit SAPUI5 konsumieren
- Implementierung der Data-Provider-Klasse
SAP HANA XSA und CDS für ABAP
- Create CDS view: The easiest way to do this is to using the annotation @OData.publish:true. The annotation is specified before the actual view implementation.
- OData-Service registrieren:
- Transaktion /IWFND/MAINT_SERVICE
ABAP channels
ABAP channels enable interactive and collaborative scenarios based on event-driven architecture. This means that when data is changed in a user session or by an external program, a server can actively inform other user sessions or external programs of this change.
There are two types of ABAP channels:
- ABAP Push Channels
- An ABAP Push Channel (APC) enables bidirectional communication with an external client - typically a web browser -via the WebSocket Protocol.
- SE80: Package>Create..more: Connectivity
- APC class
- on_accept: this method is called when a WebSocket connection is to be set up for the ABAP Push Channel.
- on_start: this method is called with the first WebSocket request.
- on_message: this method is called for each incoming message.
- METHOD if_apc_wsp_extension~on_message.
- DATA: lr_message TYPE REF TO if_apc_wsp_message.
- TRY.
- lr_message = i_message_manager->create_message( ).
- lr_message->set_text( i_message->get_text( ) ).
- i_message_manager->send( lr_message ).
- CATCH cx_apc_error.
- ENDTRY.
- ENDMETHOD.
- on_close
- on_error
Then it can be called in script:
<script>
// WebSocket-Verbindung öffnen
var ws = new WebSocket( "ws://server.domain:XXXXX/sap/bc/apc/sap/XXXXX");
ws.onopen = function() {
alert("WebSocket geöffnet");
ws.send("Hallo, Welt"); };
ws.onmessage = function (msg) {
alert(msg.data);};
ws.onclose = function() {
alert("WebSocket geschlossen");};
ws.onerror = function() {
alert("WebSocket-Fehler");};
</script>
- ABAP Messaging Channels
- An ABAP Messaging Channel (AMC) sends messages from an user session to other user sessions. These can be transferred to other user sessions via APC can also be forwarded to external clients. With ABAP Message Channels, SAP provides a publish/subscribe architecture
- Create a channel.
- Create and assign authorized programs with the role
Examples
- Sending messages from a browser (HTML5 UI) to other browsers or ABAP sessions
- Sending messages from ABAP sessions to other browsers (HTML5 UI) and ABAP sessions.
- Popup screen for requesting access permission to connected Webcam device.
- Playing table tennis including playing field and player 1 in browser and player 2 in SAP GUI.
bgRFC
Reference: bgRFC Programming (sap.com)
Combined use of the bgRFC with tRFC and qRFC in a single destination is not possible. However, for each destination we can define which communication type we want to use.
BGRFC_SUPERVISOR: We have used transaction SM59 to define the supervisor destination as an RFC destination. This destination must be defined as either an ABAP connection or a logical connection.
bgRFC Configuration
Transaction SBGRFCCONF, we can define a supervisor destination for bgRFC processing. The supervisor destination gets the configuration settings for the bgRFC scheduler and starts or stops the schedulers as required on each application server.BGRFC_SUPERVISOR: We have used transaction SM59 to define the supervisor destination as an RFC destination. This destination must be defined as either an ABAP connection or a logical connection.
A user, password, and client must be entered for
both connection types.
Creation of destination
On the Define Inbound Dest. Tab page in the transaction SBGRFCCONF, we can maintain a separate inbound destination for each application. In the attached screenshot 6 inbound destinations is maintained. This is also a mandatory step to create any inbound bgRFC. Logon/server group can be defined using transaction RZ12. For each inbound destination we can define separate server group also by clicking on the each destination name. Please refer the attached screen shot for all other settings.All the settings and activities related to the transaction SBGRFCCONF is BASIS related activity so before creating/configuring any bgRFC please consult with BASIS team.
We can create outbound destination using transaction SM59. Creation of outbound destination in SM59 is normal like any of the destination creation. Please refer the below screenshot for reference.
bgRFC Programming
1. Create an inbound destination
object
2. create a bgRFC unit
We have to use method CREATE_TRFC_UNIT to create a tRFC unit and method CREATE_QRFC_UNIT to create a qRFC unit. 
3. call any function module in background
4. Debug bgRFC unit using external break points
More examples:
bgRFC Type t: Outbound
This example creates a bgRFC unit type t that contains two function module calls and which is sent to a remote system via the outbound scheduler.DATA: my_destination TYPE REF TO if_bgrfc_destination_outbound,
my_unit TYPE REF TO if_trfc_unit_outbound,
dest_name TYPE bgrfc_dest_name_outbound.
dest_name = 'MY_DEST'.
my_destination = cl_bgrfc_destination_outbound=>create( dest_name ).
my_unit = my_destination->create_trfc_unit( ).
CALL FUNCTION 'rfc_function_1' IN BACKGROUND UNIT my_unit.
CALL FUNCTION 'rfc_function_2' IN BACKGROUND UNIT my_unit.
COMMIT WORK.bgRFC Type q: Outbound
This example creates a bgRFC unit type q that contains two function module calls and which is sent to a remote system via the outbound scheduler. To do this, queue names are used for the serialization of units. At the same time, the example explains how to intercept exceptions to be able to handle any errors. In this example, we will specify the queue names retroactively. This is technically correct, but the maintenance of the programs can suffer as a result.TRY.
dest_name = 'MY_DEST'.
my_destination = cl_bgrfc_destination_outbound=>create( dest_name ).
CATCH cx_bgrfc_invalid_destination.
MESSAGE e102(bc).
ENDTRY.
my_unit = my_destination->create_qrfc_unit( ).
TRY.
CALL FUNCTION 'rfc_function_1' IN BACKGROUND UNIT my_unit.
my_unit->add_queue_name_outbound( 'DEBITOR-1234' ).
CALL FUNCTION 'rfc_function_2' IN BACKGROUND UNIT my_unit.
queue_name = 'PRODUCT-4711'. INSERT queue_name INTO TABLE queue_names.
queue_name = 'PRODUCT-5432'. INSERT queue_name INTO TABLE queue_names.
my_unit->add_queue_names_outbound( queue_names ).
CATCH cx_qrfc_duplicate_queue_name.
MESSAGE e101(bc).
ENDTRY.
COMMIT WORK.
bgRFC Type q: Outbound to Inbound
The next example creates a bgRFC unit of type q that contains two function module calls and which is sent to a remote system using the outbound scheduler. Once there, it is placed in the inbound queue. To do this, queue names are used for the serialization of units. At the same time, we show how you can disable the exception raised for duplicate queue names, using the parameter IGNORE_DUPLICATES.DATA: my_destination TYPE REF TO if_bgrfc_destination_outbound,
my_unit TYPE REF TO if_qrfc_unit_outinbound,
dest_name TYPE bgrfc_dest_name_outbound,
queue_name TYPE qrfc_queue_name,
queue_names TYPE qrfc_queue_name_tab.
TRY.
dest_name = 'MY_DEST'.
my_destination = cl_bgrfc_destination_outbound=>create( dest_name ).
CATCH cx_bgrfc_invalid_destination.
MESSAGE e102(bc). ENDTRY.
my_unit = my_destination->create_qrfc_unit_outinbound( ).
CALL FUNCTION 'rfc_function_1' IN BACKGROUND UNIT my_unit.
CALL FUNCTION 'rfc_function_2' IN BACKGROUND UNIT my_unit.
queue_name = 'DEBITOR-1234'. INSERT queue_name INTO TABLE queue_names.
queue_name = 'PRODUCT-4711'. INSERT queue_name INTO TABLE queue_names.
queue_name = 'PRODUCT-5432'. INSERT queue_name INTO TABLE queue_names.
my_unit->add_queue_names_outbound( queue_names = queue_names
ignore_duplicates = abap_true ).
my_unit->add_queue_names_inbound( queue_names = queue_names
ignore_duplicates = abap_true ).
COMMIT WORK.
bgRFC Type t: Inbound
This example creates a bgRFC unit of type t that contains two function module calls and which is to be processed in the same system by the inbound scheduler.DATA:
my_destination TYPE REF TO if_bgrfc_destination_inbound,
my_unit TYPE REF TO if_trfc_unit_inbound,
dest_name TYPE bgrfc_dest_name_inbound.
dest_name = 'MY_DEST'.
my_destination = cl_bgrfc_destination_inbound=>create( dest_name ).
my_unit = my_destination->create_trfc_unit( ).
CALL FUNCTION 'rfc_function_1' IN BACKGROUND UNIT my_unit.
CALL FUNCTION 'rfc_function_2' IN BACKGROUND UNIT my_unit.
COMMIT WORK.
bgRFC Type q: Inbound
This is another example of an inbound bqRFC of type q. Unlike the bgRFC of type t example, we are using queue names here and, therefore, the method create_qrfc_unit instead of create_trfc_unit.DATA:
my_destination TYPE REF TO if_bgrfc_destination_inbound,
my_unit TYPE REF TO if_qrfc_unit_inbound,
queue_name TYPE qrfc_queue_name,
queue_names TYPE qrfc_queue_name_tab,
dest_name TYPE bgrfc_dest_name_inbound.
dest_name = 'MY_DEST'.
my_destination = cl_bgrfc_destination_inbound=>create( dest_name ).
my_unit = my_destination->create_qrfc_unit( ).
TRY.
CALL FUNCTION 'rfc_function_1' IN BACKGROUND UNIT my_unit.
my_unit->add_queue_name_inbound( 'DEBITOR-1234' ).
CALL FUNCTION 'rfc_function_2' IN BACKGROUND UNIT my_unit.
queue_name = 'PRODUCT-4711'.INSERT queue_name INTO TABLE queue_names.
queue_name = 'PRODUCT-5432'.INSERT queue_name INTO TABLE queue_names.
my_unit->add_queue_names_inbound( queue_names ).
CATCH cx_qrfc_duplicate_queue_name.
MESSAGE e101(bc).
ENDTRY.
COMMIT WORK.
Filling Multiple Units in Parallel
The units are processed in the same order as they were requested. In this example, unit 2 has priority over unit 1. Since both units are serialized by the same queue names, there is a sequence dependency. If different queue names were used, then both units could be processed in parallel.DATA:
my_destination TYPE REF TO if_bgrfc_destination_outbound,
my_unit_1 TYPE REF TO if_qrfc_unit_outbound,
my_unit_2 TYPE REF TO if_qrfc_unit_outbound,
dest_name TYPE bgrfc_dest_name_outbound,
queue_name TYPE qrfc_queue_name,
queue_names TYPE qrfc_queue_name_tab
TRY.
dest_name = 'MY_DEST'
my_destination = cl_bgrfc_destination_outbound=>create( dest_name )
CATCH cx_bgrfc_invalid_destination.
MESSAGE e102(bc).
ENDTRY.
my_unit_2 = my_destination->create_qrfc_unit( ).
my_unit_1 = my_destination->create_qrfc_unit( ).
CALL FUNCTION 'rfc_function_1' IN BACKGROUND UNIT my_unit_1.
CALL FUNCTION 'rfc_function_2' IN BACKGROUND UNIT my_unit_2.
queue_name = 'DEBITOR-1234'. INSERT queue_name INTO TABLE queue_names.
queue_name = 'PRODUCT-4711'. INSERT queue_name INTO TABLE queue_names.
queue_name = 'PRODUCT-5432' INSERT queue_name INTO TABLE queue_names.
my_unit_1->add_queue_names_outbound( queue_names = queue_names ignore_duplicates = abap_true )
my_unit_2->add_queue_names_outbound( queue_names = queue_names ignore_duplicates = abap_true )
COMMIT WORK.
Information
2183108 - t/qRFC processing: general performance verifications
- Monitor the processing of t/qRFC entries through the transactions SMQ1, SMQ2 and/or SM58;
- Monitor the t/qRFC schedulers through the transaction SMQS or SMQR;
- Monitor the system behavior through the transaction SM50 or SM66.
1793313 - ALE: IDoc inbound processing using bgRFC as standard
IDocs with the status 64 are generally processed using scheduled batch jobs for the report RBDAPP01. You want to have the option to completely or partially do without these jobs while using the available system resources in an ideal manner.
Transactional processing
In the transactional processing, the inbound IDocs are processed in parallel. The current logical unit of work (LUW) is terminated when you save the IDoc with the status 64. An asynchronous RFC call executes the further processing when using the priority "01" in another LUW. If no more resources are available to the RFC, a transactional bgRFC call carries out the processing. When you use the priorities "02" to "99", the transactional bgRFC call generally carries out the processing using the inbound destinations that are assigned to the priorities.
Use transaction SBGRFCCONF to create inbound destinations. If no prefix is assigned, the system uses the automatic queue names with the prefix ALE_INB_. Alternatively, you can define your own prefix that is then used for the creation of the queue name. Destinations with multiple prefixes cannot be used. See Note 5 for further settings.
Inbound groups later classify the inbound partner profiles that you use. Carry out the transaction WE20BGRFC point "bgRFC Inbound Groups" and create the required number of inbound groups.
You can now assign the used priorities from point b) to inbound destinations. For this, carry out transaction WE20BGRFC point "bgRFC Inbound Groups". In change mode, all priorities now display that you have assigned to the inbound groups (point b)). You can enter only one entry for each priority.
e transaction WE20 to assign inbound groups to the inbound partner profiles. For this, the additional pushbutton "Options" is available in the individual view for the inbound options. You can assign an inbound group for the parameter GROUPID using a dropdown list.
If you decide at a lager stage that a certain inbound group is to use a different priority and therefore a different inbound destination, you do not need to change the individual partner profiles; instead you can simply change the assignment when defining the inbound groups (point b)).
In addition, transaction WE20BGRFC also offers the option "Mass Change" to change partners according to their selection.
Queued processing
During the queued processing, the inbound IDocs are processed depending on their queue names. The current logical unit of work (LUW) is also terminated when you save the IDoc with the status 64. Further processing happens independent of the chosen priority. It is generally carried out by a queued bgRFC call using the inbound destinations that are assigned to the priorities. IDocs with the same queue name are processed sequentially and queues with different names are processed in parallel.
Note that this processing works as an isolation and not EOIO (exactly once in order). Processing is not stopped after an incorrect IDoc, but proceeds depending on the result of the ES IDOC_INPUT_REPROCESS.
When you use transaction WE20BGRFC point "Rules for Queue Name Creation" or transaction WE85_INBOUND, you can view rules or store your own rules. You can find the required interface in the assigned function modules IDOC_QUEUE_INB_CONST_ALE_QUEUE or IDOC_QUEUE_INB_MESTYP.
The other required settings are identical to the steps a) to d) of the transactional processing. In addition, you have to choose only "Options" in inbound partner profiles (transaction WE20) to assign a rule. You can assign a rule for the parameter RULE_NAME using a dropdown list.
Reprocessing IDocs in case of an error
To avoid an infinitely high number of repetitions or for the general activation of the function, a new global parameter is introduced that restricts the number of possible repetitions. Use transaction OYEA to store a value between 1 and 99 for the parameter "Number of Repetitions".
Comments
Post a Comment