Outbound Idocs-FM MASTER_IDOC_DISTRIBUTE

Hi,
We have a standalone report, which sends outbound idoc. As per our basis consultant it seems that the idocs after being generated are stuck in the qRFC queue for a long time, which is causing issues.
He has suggested that we call the function module MASTER_IDOC_DISTRIBUTE in BACKGROUND TASK instead of calling it just like that.
1) Should it be background task or update task?
2) What is the significance of calling it in background task or update task?
3) What is the qRFC queue?
Thanks in advance,
Mick

follow the link
www.erpgenie.com/sapgenie/docs/ale_whitepaper.doc
www.sapbrainsonline.com/ARTICLES/TECHNICAL/ALE/ALE_INTRODUCTION.html - 80k
www.erpgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
QRFC QUEUE
All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC). RFCs can be used to start applications in remote systems, and to execute particular functions.
Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.
Communication between applications within an SAP system and also with a remote system can basically be achieved using the Remote Function Call (RFC). Here, the following scenarios are possible:
·         Communication between two independent SAP systems
·         Communication between a calling SAP system and an external receiving system
·         Communication between a calling external system and an SAP receiving system
The following communication model shows what these communication scenarios may look like in reality. The actual sending process is still done by the tRFC (transactional Remote Function Call). Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also called the client system, while the target system corresponds to the server system.
In practice, the following three scenarios for data transfer exist:
Scenario 1: tRFC
This scenario is appropriate is the data being sent is independent of each other. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, data is transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed one time only. You cannot define the sequence in which the function modules are executed, nor the time of execution. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again after 15 minutes.
Scenario 2: qRFC with outbound queue
In this scenario, the sender system uses an outbound queue, to serialize the data that is being sent. This means that function modules which depend on each other (such as update and then change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming code of the server system must not be changed. However, it must be tRFC-capable.)
Scenario 3: qRFC with inbound queue (and outbound queue)
In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in the sender system. This guarantees the sequence and efficiently controls the resources in the client system and server system. The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with inbound queue in the server system is not possible, since the outbound queue is needed in the client system, in order to guarantee the sequence and to prevent individual applications from blocking all work processes in the client system.
Properties of the Three Communication Types
To help you decide which communication type you should use in your system landscape for your requirements, the advantages of the three communication types are listed below:
       1.      tRFC: for independent function modules only
       2.      qRFC with outbound queue: guarantees that independent function modules are sent one after each other and one time only (serialization). Suitable for communication with non-SAP servers.
       3.      qRFC with inbound queue: in addition to the outbound queue in the client system, an inbound queue makes sure that only as many function modules are processed in the target system (server) as the current resources allow. Client and server system must be SAP systems. One work process is used for each inbound queue.
for detailed information
http://help.sap.com/saphelp_nw2004s/helpdata/en/b0/eae2a889e711d2956500a0c94260a5/frameset.htm
Edited by: sharad narayan on Apr 11, 2008 11:46 AM

Similar Messages

Outbound idocs getting delyed sometimes

Hi All,
I am generating outbound idocs using master_idoc_distribute FM and sending to Tibco..my issue is some times idocs reaches very late (15min) and some times fast even I choose tigger immediately option in we20..could any body tell me what would be the reason..
Below is my code..
Call Master_idoc_distribute
Commit work..
If I use FM: 'EDI_DOCUMENT_DEQUEUE_LATER' before commit work..does it rectifies my problem..or anything else I have to performu2026.please let me know..

Hi,
Try using the statment
call function 'DEQUEUE_ALL'.
See Standard function module "MASTERIDOC_CREATE_REQ_MATMAS", line no 1049 for reference.
Regards
Vinod

Call Master_idoc_distribute for collective outbound idocs

Hi All,
I want to process outbound idocs (4 idocs collectively) using master_idoc_distribute FM. I am calling master_idoc_distribute inside a FM and assigned it to process code outbound. It is working for one idoc but not for 4 idocs.
How can i call the master_idoc_distribute for sending out 4 idocs one at a time.
Thanks

Ok. I guess the requirement was wrongly typed. Ok here is the requirement.
I basically want to take a collective idoc in R/3 and cal master_idoc_distribute to create and send idocs. This is my collective idoc structure.
EDIDC
--+ E1STZUM
--+ E1STZUM
where 'E1STZUM' repeats for each idocs. In the above structure, there are two idocs in one idoc which is a collective idoc. So i want to write a logic to take the first segment E1STZUM and call master_idoc_distribute and then call the second segment E1STZUM and call master_idoc_distribute FM again and so on depends on how many segments. How can i write a logic to loop at idoc_data and call FM master_idoc_distribute. I am not a core ABAP programer. So pls do send me sample code with comments if possible.
Thanks a lot.

Duplicate Outbound IDocs getting Triggered at the same time.

Hi Folks,
I have created custom outbound idoc and done all the configurations required like WE20, WE30, WE31, WE81, WE82, WE 41, WE57 etc.
Also I have written my code to populate segments and then call MASTER_IDOC_DISTRIBUTE in the custom function module which is assigned to the process code and also done the configurations like we57 etc. for the same.
Now when I trigger my output type from VL74 transaction, I noticed two entries in we02 resulting in two IDocs generated for 1 HU.
The difference in two IDocs is the first IDoc getting generated in error with status 29. While the second one as success with status 03.
The data records containing segments have same values for both the IDocs number.
Whether the configuration is a issue here or problem in code of custom fm?
Please help.

Hi Anil,
Appreciate your quick response.
In my custom FM I have populated an internal table it_master_idoc_data with two records of two segments, containing segment name in SEGNAM filed and segment data in SDATA field.
Please let me know whether the data in this internal table of structure EDIDD sufficient for passing to MASTER_IDOC_DISTRIBUTE FM? Or do I need to populate any other field of EDIDD.
Also I am exporting a structure master_idoc_control containing values in this 5 fields.
MESTYP = Z message type, Z IDOCTP, partner and details in RCVPOR, RCVPRN, RCVPRT fields.
I am not populating the internal table communication_idoc_control while calling FM MASTER_IDOC_DISTRIBUTE from my custom function module.
After executing MASTER_IDOC_DISTRIBUTE FM, when the control comes back to my custom FM there is one record in communication_idoc_control internal table with IDoc number in DOCNUM field with status 29(error). Now when we check in WE02 there are two IDocs generated after this transaction's execution.
The first one in error which FM MASTER_IDOC_DISTRIBUTE returns and second one in success with status 03.
Please help....
Thanks,
Pravesh

FM to fill outbound IDOC with change document details.

Hi ,
I am working on an enhancement EXIT_SAPLMGMU_001 for an interface to track the changes to the material master.
Can someone please let me know if there is a FM to populate outbound IDOC with change document details like when a material is
created /changed. Thanks much.
Regards,
Sanjeev
Edited by: sanjeev.s on Apr 14, 2010 3:32 PM

Call the function module "MASTER_IDOC_DISTRIBUTE" to create idoc. Use function module "CHANGEDOCUMENT_READ_HEADERS" to get the change document details.
Regards
Vinod

FM for ORDERS05 Outbound Idoc.

Hi,
I have to post an idoc of basic type ORDERS05 from a custom program.
I have populated the fields for control header and the data section of the idoc.I tried using the FM IDOC_OUTPUT_ORDERS to post the idoc,but when I went and checked in WE05,there were no idoc created.I don't understand why the idoc's are not been created.Could you help me in knowing how to use the FM IDOC_OUTPUT_ORDERS or if there are any other FM's to post an outbound idoc.
Please reply asap.
Thanks,
Sandeep.

Hi,
There is a exit in the FM IDOC_OUTPUT_ORDERS line no 50... double click on the '001' it will take u to the Function Module EXIT_SAPLEINM_001... there click on the Zprogram ...
The FM has EKKO table fields has a Impirting parameter .
u write a code in that Z include program
u have to call the FM MASTER_IDOC_DISTRIBUTE in the program
which creates the IDOC
Thanks,
Manjunath MS

Function Module to create Outbound IDoc

I have created a segment (ZSEGPRO), basic type (ZIDOCPRO) and message type (ZMSGPRO) to create a custom IDoc. Now I have to write a Function Module to create Outbound IDoc.
I want to know what will be in Import, Export, Changing, Tables, Exceptions and Source code of that function module. The fields used in the segment ZSEGPRO is given below:
Fld NameSource Data Elmn     Description
PRODUCT MARA MATNR     Material number
TEXT     MAKT     MAKTX     Material description
PRN     MARA     YYBCEZNDR     Print Field
Additional information: Export parameter will be BAPIRETURN for holding error message(if any).
These Function Module need not require to be RFC enabled.

Hi ,
Refer these:
There are two main reasons
1) Make sure you call COMMIT WORK after the MASTER_IDOC_DISTRIBUTE
http://help.sap.com/saphelp_nw04/helpdata/en/78/21783151ce11d189570000e829fbbd/content.htm
2) The rest of the setting of the ALE IDoc might not have been done
http://help.sap.com/saphelp_46c/helpdata/en/78/2177c951ce11d189570000e829fbbd/frameset.htm
You can use the Area Menu WEDI and do the rest of the settings.
ALE Quick Start guide and ALE Programming Guides for your reference
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/CABFAALEQS/CABFAALEQS.pdf
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCMIDALEPRO/BCMIDALEPRO.pdf
Recent discussion which could be helpful,
About WE21, BD64, sm59
Regards
Shiva Kumar

About Orders05 outbound Idoc.

Hi,
I am using an outbound idoc of basic type Orders05 with an extension of the idoc header segment.This outbound idoc will get triggered once a PO is saved and sent through EDI.
I have to do an enhancement wherein I have to populate the mode of transport field(EXPVZ) and place of loading(LADEL) in the fields of the extended segment selecting them from EIKP depending upon the BELNR value in the header of the idoc(E1EDK01-BELNR).
I am unable to understand how do I populate the fields.
Could you please help me.
Thanks,
Sandeep.

HI,
see the below steps you will completely understand the processing outbound..
2.1 Outbound Interface
PROCESS DIAGRAM
Outbound Interface
1. Analyse Hierarchy Levels
2. Create New segment
3. Create New IDoc Type
4. Create New Message Type
5. Link Message with IDoc Type
6. Create an entry in EDP13 via transactions WE20 and BD64
7. Populate the Custom IDoc via ABAP Program
7b Error Handling
7c. Send Status Email
8. Test the Population of the Custom IDoc
Step 1 Analyse Hierarchy Levels:
Analyse the data relationships being processed in the interface. Define the appropriate hierarchical Parent-to-Child relationships.
Navigate to transaction code WEDI
Transaction WEDI displays the IDOC main menu. This allows navigation around the various development and control areas to create a customised IDOC.
Step 2 Create a new segment:
via wedi : Development - IDOC Segments or Transaction code WE31.
 Enter segment name and click on Create.
 The name of the segment type must start with Z1 , and have a maximum of eight characters.
 Enter description and enter the relevant field names and data elements.
 The segment should represent a structure in the program so for each field in the segment a field name and a data element must be defined.
 Save the segment and enter Person Responsible and Processing Person .
 Go to Edit and Set Release.
 Repeat this procedure for each new Segment in the IDOC.
Step 3 Create a new IDOC Type
via wedi Development - IDOC Types or Transaction WE30.
 Enter segment name (starting with Z), click on Basic Type and then Create.
 Create as new, enter Person Responsible and Processing Person and enter description.
 On Create Basic Type screen decide where segments should be inserted and go to Edit/Create Segment.
 Complete relevant fields in the Maintain Attributes screen:
 From the relevant segments created in Step 2 enter the Segment type and if mandatory segment.
 The Minimum and Maximum number of segments to be allowed in the sequence. (One minimum and one maximum if segment is mandatory).
 The Parent Segment and Hierarchy Level will be automatically created depending on where in the IDOC tree you decided to create that particular segment.
 Repeat this process for each segment needed in the IDOC type, deciding whether to add the next segments at the same level or as a Child.
 When IDOC created return to initial screen. Go to Edit and Set Release.
 Go to Transaction WE60 to view the IDoc Type you have created.
Step 4 Create new Message Type
via wedi Development - Message Types or Transaction WE81.
 Display/Change and click on New Entries
 Create a new Message Type and Save.
Step 5 Link Message Type to IDOC Type
via wedi Development - IDOC Type/Message or Transaction WE82.
 Display/Change and then click on New Entries.
 Enter Message Type, Basic Type (IDOC Type) and Release (46C) and Save.
Step 6 Create an entry in EDP13 via transactions WE20 and BD64.
The partner profile for the Idoc must be set up and generated in the transaction BD64 and transaction WE20.
 WE20 Add Message Type to appropriate Partner Type, Enter Message Type, Receiver Port and Idoc Type and Save.
 BD64 Create a Model View, Enter Sender and Receiver Ports, Attach Message Type. Go to Environment on Menu and click on Generate Partner Profiles and generate (not save) profile.
Step 7 Populate the custom IDOC via ABAP Program
See Test Program ZOUTBD_IDOC_TEMPLATE, Appendix IV.
 Create an Internal Table for each segment type, this should be exactly the same structure as the segment type.
 The control record is filled into a structure like EDIDC. The message type and the Idoc type for the Idoc must be populated into the eddic structure.
- PERFORM populate_Control_structure USING c_mestyp
 c_SEGMENT_type1.
 The data segments are filled into a structure like edidd-sdata; sdata and the segment name are populated into the edidd structure.
- PERFORM transfer_Parent_data_to_seg.
 The standard SAP function module MASTER_IDOC_DISTRIBUTE is called to pass the populated IDOC to the ALE Layer.
- PERFORM master_idoc_distribute.
 NOTE: This function module is only called for stand alone programs and Shared Master Data programs (SMD). It is not called when using extensions or output determination.
 The ALE Layer handles the sending of the IDOC to the receiving system.
 Error Handling (see Step 7b).
 Commit work.
Project Specific
Step 7b Error Handling Analyse which fields in the interface are mandatory for the receiving system and who needs to receive error notification.
 Declare a structure of type MCMAILOBJ for sending instructions.
 Enter values for the internal table based on structure MCMAILOBJ
 For selection processes, on SY-SUBRC checks and where fields are mandatory for the receiving system; insert Function Module MC_SEND_MAIL.
 Enter values in the following parameters: -
MS_MAIL_SENDMODE = B (Batch Mode)
MS_MAIL_TITLE = 'Mail Title'
MS_MAIL_DESCRIPTION = Error description (e.g. MATNR not given)
MS_MAIL_RECEIVER = Name of Receiver (To be determined)
MS_MAIL_EXPRESS = E (Express Delivery)
MS_MAIL_DLINAME = Leave Blank
MS_MAIL_LANGU = 'E' (Language)
MS_MAIL_FUNKOBJ_NAME = Leave Blank
TABLES
 MS_MAIL_CONT = I_MCMAILOBJ
Note:
It has to be determined separately for each interface how these errors and mail notifications are to be grouped dependant upon the number of errors that are potentially likely. One possible approach is to send an email for each reason for rejection and include all the records that failed for that reason in the mail notification. Another possible approach is to send an email for every failure.
When error checking for mandatory fields it is common SAP practice to reject a record on its first failure (irrespective of subsequent errors in that record)
Step 7c Send status mail
 Append to table I_MCMAILOBJ details of the time the interface was processed, how many Idocs were created and how many of these produced a status of 03.
 Select the user to receive the mail from ZINT_RECEIVER, using the name of the program as a key (SY-CPROG).
 Use function Module MC_SEND_MAIL to send a mail to the user containing the contents of I_MCMAILOBJ at the end of the interface processing.
Step 8 Test the population of the custom IDOC
via wedi IDoc - Display IDoc or Transaction WE02.
 Enter your message type and execute.
 Status should be green, double click on one of the Idocs you have created to view its contents.
 If a problem has occurred click on Status which will give you a description of the error.
 Drop down Data Records arrow and this should list the data in the IDoc in the correct hierarchical structure.
 Click on each individual segment and view the content to check that the correct data has been read.
 If you have UNIX access by using AL11 you can view the file that you have created.
Note:
For some interfaces it may be valid to send an empty file to SAP. This empty file is converted to the custom IDOC format expected by SAP. This custom IDOC will contain dummy information. In the inbound processing code, if the dummy information is identified then the processing of the IDOC is considered to be complete and the IDOC should then be assigned a successfully processed status of 53, even though it has not been processed at all.
rewards if useful
regards,
nazeer

Outbound IDocs are not visuible in Middleware system(SeeBeyond)

Hi Experts,
We need need your expertise help on this issue.
Issue:
The Outbound IDocs which are in status 12 in SAP system are not visuible in Middleware system(SeeBeyond) for customized message type( forecast -ZFOSHT)
If we create a IDoc by using customized program, IDoc(eg.0000000012345678) is successfully created and the status of IDoc is 12. but not visible in Seebeyond.
but If we are re sending the same IDoc(0000000012345678) through WE19(IDoc creation) without changing any thing,the newely created IDoc reached to the Seebeyond.
Please look the issue and help me on this.
Raghavendrarao.R
+91 9739006564

Hi,
After your Function module for IDoc creation either it is Z function module or standard one "MASTER_IDOC_DISTRIBUTE" write these
CALL FUNCTION 'DB_COMMIT'.
CALL FUNCTION 'DEQUEUE_ALL'.
COMMIT WORK.
This should solve your problem.

Outbound IDOC - Sender and reciever

Hello SDNites,
I have created a report pgm which is equipped to send an outbound IDOC i.e used FM 'MASTER_IDOC_DISTRIBUTE'. Can someone please tell me how do I decide my sender and reciever when populating the control record in this FM.
I know sender will be my system and reciver will be third party system but can you please tell me what values need to be opulated there or

Thanks for the information,
Can you please give the info in following form,
1. Partner profile configuration with the values in your system.
2. Code snippet where control records are poulated for Outbound IDOC with the values you specified in step 1.
This will help me in understanding the same.
Regards,
Abhi

How to send Outbound IDocs through an RFC-enabled FM

Good day to all;
A partner system (AS/400) wants to use a Java Connection to execute a RFC Function Module, in SAP, that will then return a collection of IDocs.
Currently, the Function Module builds the IDocs, but I'm not exactly sure how to simply send those IDocs back to the AS/400.
If anyone can help in this regard, that would be great.
My current thoughts are to use Master_IDoc_Distribute, but then I imagine that requires a port configuration for the AS/400. And if this is the case, does that mean that SAP will send the IDocs back itself instead of using the RFC interface?

Hi Tavares,
If you want to send outbound IDoc to AS/400 (external system), you need to setup file port (t/code WE21).
For RFC interface, you need to setup RFC file port with RFC Destination (t/code SM59). In this case, SAP will send IDoc (individually or batch) to receiver system (AS/400). Perhaps you need a middleware for data transformation, if AS/400 does not perform data mapping for outbound IDoc.
For FTP interface, you need to setup flat/XML file port for outbound. then you can FTP the file to AS/400 later on.
In addition to file port configuration, you also need to setup partner profile for outbound parameter (t/code WE20) and the distribution model (t/code BD64).
Hope this will help.
Regards,
Ferry Lianto

Process Code in outbound IDOC

Hi,
We have created a process code for outbound IDOC and assigned an FM to it.In that FM, code is written to generate an IDOC(FM 'master_idoc_distribute').Please let us know how to trigger the outbound IDOC using the process code.Are there any FM or standard programs??
Regards
Prathima

Hi Prathima,
For outbond Idoc you have to define the output parameters for the corresponding Partner profile (transaction WE20). Look there that there is a tab called Messages control to specify and aplication, a message class and a process code. Is here where you have to add the process code.
The application/message is responsible of select the data adapted for the FM linked to the process code.
Reward points if helps.
Roger

RE: Posting OUTBOUND idocs

Hello IDOC gurus,
I am creating OUTBOUND idocs in the background using function module MASTER_IDOC_DISTRIBUTE. My question is will this function module process the idoc or do I have to run program RSEOUT00 as a batch job to process the idoc. If this is the case how do I monitor error messages. I need to get them into the application log which I can do if FM MASTER_IDOC_DISTRIBUTE. will do the job.
Please advise
Thanks

I am creating OUTBOUND idocs in the background using function module MASTER_IDOC_DISTRIBUTE. My question is will this function module process the idoc or do I have to run program RSEOUT00 as a batch job to process the idoc.
Yes, You will have to run RSEOUT00 as periodic job
If this is the case how do I monitor error messages. I need to get them into the application log which I can do if FM MASTER_IDOC_DISTRIBUTE. will do the job.
BD87

Regarding Outbound IDOC for Goods Receipt with MBGMCR03

Hi Experts,
Please let me know ,how to handle TYPE QUANT fields when i am generating an Outbound IDOC for Goods receipt for message type MBGMCR with the IDOC type MBGMCR03.
At item level when passing the value for quantity received field ,the QUAN value into NUMC or CHAR before MASTER_IDOC_DISTRIBUTE to pass it to data record it is showing correctly in my BADI .
after generating the idoc , the field value is appended with next field value passed.
before generating IDOC
erfmg( 60.000) - ENTRY_QTY(060)
efrme (EA)       - ENTRY-UOM(EA)
after generating IDOC
IN WE02
ENTRY_QTY-060EA
later field values are mismatching .
Please let me know the resolution.
Thanks & regards
Vishnu

Hi,
     Standard Idoc types for invoice is INVOIC01 and INVOIC02.
- Use WE30 for seeing Idoc types with segment.
Or otherwise go for Custom Idoc
           Create Custom Idoc type with required fields,custom output type and assign it to partner profiles.(If there is no std idoc type or output type)
          Use Funtion module MASTER_IDOC_DISTRIBUTE to generate Idocs while saving MIRO, for this you need to find exit or implement implicit enhancement while saving MIRO.
http://wiki.sdn.sap.com/wiki/display/ABAP/StepstocreatecustomIDOC - Creating Custom idocs

Outbound IDoc for Goods Movement

HI
We need to generate XML files for goods movement posted in SAP at Goods Receipt (MIGO) and Post Goods Issue (VL02N). Requirement is asynchronous update where the receiving system will poll the xml file at the end of the day.
I have not been able to find any standard outbound idoc for goods movement.Can someone advise how they tackled any similar requirement? Any other approach also appreciated.
Thanks
Sriram

Answer to the question, which would be useful to all.
MIGO
MB_CF001 - Customer Function Exit in the Case of Updating a Mat. Doc.
This exit is called on update task, populate segments (edidc & edidd) of WMMBID02 (WMMBXY message type) and use MASTER_IDOC_DISTRIBUTE. Also you need to maintain the ALE Distribution model in WE64 for this message type.
Inside the code you can restrict based on movement type. No need to issue COMMIT.
VL02N
You can use BAdi: LE_SHP_DELIVERY_PROC to perform this.
Create Implementation and use the method SAVE_AND_PUBLISH_DOCUMENT.
Hope this help to others as well.

Outbound Idocs-FM MASTER_IDOC_DISTRIBUTE

Similar Messages

Maybe you are looking for