Ale/idoc issue.

dear all,
i want to post the idoc for sinlge personal no.that means sinlge from sap hr client  to other client.how to place the condition.how to trigger this idoc.

HI,
The T-code is PFAL(RHALEINI).
Thanks & Regards
Manas

Similar Messages

  • ALE-IDOC ISSUE(material getting locked for enhancement)

    Dear all,
    I have extended the idoc and enhanced inbound material master function module to suite the requirement .
    The challenge is that the material is getting locked when the material sent from bd10 and prodction version view for which function module extended is not getting created.The error log says that "material is locked".But when the idoc is processed again from we19 the material is not getting locked and PV(production version is successfully created).
    Can anybody guide me how this locking issue can be resolved?(have done unlock -lock before and after BDC for Production version).
    Thanks.

    Hi,
    If some one using the same material in another session, definitely the idoc will fail as the material is locked... In order to overcome this first lock the material u want to send, if doing this u get foreign lock then u will know that already someone locked it , so once gain process the same record until the foreign lock is gone, once it is gone process ur record and then unlock the material.
    Regards,
    Nagaraj

  • ALE-IDocs: Issue on COGRP1 & COGRP6 Message Types

    Dear Experts,
    I need to send the Cost center groups data and Profit Center groups data from one system to other, I had sent this for one time using the tcodes, from now on I need to send only the changed data, so configured the ALE for this.
    I activated change pointers generally in BD61 and then activated change pointers for message types in BD50. Cost Center Group (COGRP1), Profit Center Group (COGRP6).
    Why is RBDMIDOC program not showing any output when executed with standard message types COGRP1 and COGRP6 ?
    It is working fine with other message types like MATMAS, DEBMAS, COSMAS, PRCMAS, CREMAS.
    Tcode: BD59: Assignment of Object Type to Message
    Tcode: WE30: Develop IDoc Types
    Tcode: BD52: Change document items for message type
    So, COGRP1 does not have assignment of all the segments that are displayed for the IDoc Type: COGRP01 in WE30. Do we need to assign all these segments and fields to the message type in BD59? If so, how to create this ALE Object Types and what are these table names and fields in BD52., any user exits kind of thing for populating the fields if we do this way?
    I am really having trouble and great confusion with this.
    I would really appreciate you if you could provide me an answer or a hint.
    Thanks in advance for the time you spent on this.
    RV

    Hi,
    You need to follow following steps for the activation of change pointer.
    1) Enable change pointer globally <b>(BD61)</b>
    2) Enable Change Pointers for a Message Type <b>(BD50)</b>
    3) Specify the Fields for Which Change Pointers Are to Be Written <b>(BD52).</b>
    <b>BD59</b> is used to Assign Filter Object Type to IDoc Field. Then you can add filter while creating distribution model.This is used when you have to filter the Idoc at distribution stage. It has nothing to do with the change pointer technique.
    In BD52 , you have to assign the change pointer object(this you can find using <b>T.code SCDO</b>), table name and field.In your case change doc object is <b>ALESETS</b>
    Just make sure that you are making changes in Cost center groups data and Profit Center groups and then execute program RBDMIDOC.
    Regards,
    Monika

  • Issue in transporting changed material type using ALE-IDOC

    Hi All,
    I am sending the material master data from one system to another using ALE-IDOC.The issue is that teh material type is not getting sent from one system to another after changing the material type.I mean the changes in material type are not getting updated.I will be indeed thankful if anyone can guide me resolve this issue.
    Thanks.

    Hi,
    Not all the fields that are changed in material master are sent in the Idoc. Material type is one such field.
    Create change pointer on some other field ex. net value or material desc. and transfer the material type changes under it.
    KR Jaideep,

  • Help: one request using ALE&IDOC to Posting Goods Issue about MaterialScrap

    Hi Exports,
    i got a situation. My client is using ALE&IDOC to deal with the Material Scrapping. The business scenario is:
    1. One third system (Non-SAP) Send IDOC to SAP Production Server through the Intermedia SEEBEYOND.
        Message Type: MBGMCR
        IDOC Type: MBGMCR02
        BUSINESS OBJECT: BUS2017
    2. SAP Production Server use "Message Type: MBGMCR" to find out the BAPI in Distribution Model and trigger the BAPI.
    the Distribution Model:
    Model View
    SEEBEYONG
    PRODUCTION
    GoodsMovement.CreateFromData
    Reciever determination: no filter
    Now my client's request is:
    When the Movement Type is 551 in the IDOC Segment "E1BP2017_GM_ITEM_CREATE", This IDOC will be ignore and not trigger the BAPI to post goods issue.
    i try to add the destination filter in the Distribution Model. but when i add the filter group, there are only two filter parameter ("Plant" and "Storage Location") and don't allow to add others.
    i have no idea now. can anyone give me a favor. thank you very much in advance.
    Edited by: Dave Wang on Feb 29, 2008 7:09 AM

    We got hold of the Idoc type 'DELVRY03 PGI SHPCON' we are able to post the Idoc but we are able to do the packing only or we are able to change the deliveries but the PGI is not happening..
    please help us on this.. is there some condig that updates the delivery with the PGi or is there something else do be done in the Idoc....
    will provide additional details if required.
    Thanks
    Arun

  • Issues in employee replication from ECC to CRM through ALE/IDOC

    Hi,
    We are replicating the employees from ECC to CRM through ALE/IDOC.
    Some times for some employees, the Idoc status in CRM is  52(Application document not fully posted) in CRM (WE02 tcode)
    If I see the details its showing as " Identification Category BPCCOD is Not Assigned to Any Identification Type"
    What I need to do now to avoid this.
    Pl suggest
    Regards
    BABU.

    Hi Babu, I'm having the same error when I replicate my employes. I have define  BPCCOD in  spro - Cross-Application Components - SAP Business Partner - Business Partner - Basic Settings - Identification Numbers,  but this configuration does not resolve my problem.
    Could you resolve this problem?.
    Pls. let me know...
    Regards,
    George

  • LSMW: ALE/IDOC, getting the Create a partner profile for message type

    Hi Gurus,
    In my current project, i need to upload the employee data using the ALE/IDOC method with the LSMW
    when i'm generating the idoc in the 13th step, its posing the information message stating that:
    Create a partner profile for message type 'ZEMP_MSG'
    In partner profile i already assigned the message type .
    How to solve this issue, <inappropriate urgency removed by moderator>
    Thnks&regards,
    sree
    Edited by: Thomas Zloch on May 13, 2011 9:55 AM

    This forum's aim is not only to search for information and ask the members questions, but also to share knowledge. When you have asked a question and found a solution, do share with the rest.

  • Upgrade impact on ALE, IDOC, RFC & XI

    Hi all
    We are having SAP R/3 4.6c and planning to upgrade ECC 6.0. Please tell me what are impacts on ALE, IDOC, RFC & XI integrations.
    Thanks in Advance.
    Raju

    During Upgrade...
    ALE : ALE Customer Distribution Model ajustments due to changes in underlying structures and fields in Idoc Segments
    We need to adjust the CDM as to adopt these to new ECC6.0 enviroment.
    IDOC : Many of the new IDOCS are not released by SAP hence it happens that these IDOCs get stucked in ALE Communication layer and hence we need to see that IDOC's in use or to be used are released by SAP.
    SAP supports these release issues ...
    Also check the Message Control Settings which needs to be checked and verified during upgrade..
    Interface Mappings : - IDOC to Non SAP systems..Proper rights access should be checked...
    Authorisations, Access rights for Directories ...
    These are the main areas which you should look upon and rest of the things will be known to you once your Business Process testing will start
    Thanks and Regards
    Pushkar Joshi

  • REG:ALE,IDoc , RFC

    HI,
    PLEASE SEND ANY GOOD MTERIAL FOR ALE IDOC , RFC.
    THANK YOU
    ASHOK KUMAR

    hi,
    <b>ALE / IDOC</b>
    http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
    http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
    http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
    http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
    http://www.sapgenie.com/sapedi/index.htm
    http://www.sappoint.com/abap/ale.pdf
    http://www.sappoint.com/abap/ale2.pdf
    http://www.sapgenie.com/sapedi/idoc_abap.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm
    http://www.allsaplinks.com/idoc_sample.html
    http://www.sappoint.com/abap.html
    http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
    http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
    http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
    http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
    http://www.sapgenie.com/sapedi/index.htm
    http://www.allsaplinks.com/idoc_sample.html
    ALE/ IDOC/ XML
    http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
    http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp
    http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm
    IDOC Convertion
    /people/kevin.wilson2/blog/2005/12/07/changing-fields-in-an-idoc-segment
    http://www.sappoint.com/abap/ale.pdf
    http://www.sappoint.com/abap/ale2.pdf
    http://www.sapgenie.com/ale/configuration.htm
    http://www.sappoint.com/abap/ale.pdf
    http://www.sappoint.com/abap/ale2.pdf
    http://www.sapdevelopment.co.uk/training
    http://www.sapgenie.com/ale/why_ale.htm
    http://www.sapdevelopment.co.uk/training
    http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
    ALE/ IDOC
    http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
    http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
    http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
    http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
    http://www.sapgenie.com/sapedi/index.htm
    http://www.sappoint.com/abap/ale.pdf
    http://www.sappoint.com/abap/ale2.pdf
    http://www.sapgenie.com/sapedi/idoc_abap.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a60bb507d11d18ee90000e8366fc2/frameset.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/78/217da751ce11d189570000e829fbbd/frameset.htm
    http://www.allsaplinks.com/idoc_sample.html
    http://www.sappoint.com/abap.html
    http://help.sap.com/saphelp_erp2004/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
    http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
    http://edocs.bea.com/elink/adapter/r3/userhtm/ale.htm#1008419
    http://www.netweaverguru.com/EDI/HTML/IDocBook.htm
    http://www.sapgenie.com/sapedi/index.htm
    http://www.allsaplinks.com/idoc_sample.html
    ALE/ IDOC/ XML
    http://www.sapgenie.com/sapgenie/docs/ale_scenario_development_procedure.doc
    http://www.thespot4sap.com/Articles/SAP_XML_Business_Integration.asp
    http://help.sap.com/saphelp_srm30/helpdata/en/72/0fe1385bed2815e10000000a114084/content.htm
    You need to create idocs for the same. Have a look at below link.It will heip you surely.
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVEDI/CAEDI.pdf
    To Create Idoc we need to follow these steps:
    Create Segment ( WE31)
    Create Idoc Type ( WE30 )
    Create Message Type ( WE81 )
    Assign Idoc Type to Message Type ( WE82 )
    Creating a Segment
    Go to transaction code WE31
    Enter the name for your segment type and click on the Create icon
    Type the short text
    Enter the variable names and data elements
    Save it and go back
    Go to Edit -> Set Release
    Follow steps to create more number of segments
    Create IDOC Type
    Go to transaction code WE30
    Enter the Object Name, select Basic type and click Create icon
    Select the create new option and enter a description for your basic IDOC type and press enter
    Select the IDOC Name and click Create icon
    The system prompts us to enter a segment type and its attributes
    Choose the appropriate values and press Enter
    The system transfers the name of the segment type to the IDOC editor.
    Follow these steps to add more number of segments to Parent or as Parent-child relation
    Save it and go back
    Go to Edit -> Set release
    Create Message Type
    Go to transaction code WE81
    Change the details from Display mode to Change mode
    After selection, the system will give this message “The table is cross-client (see Help for further info)”. Press Enter
    Click New Entries to create new Message Type
    Fill details
    Save it and go back
    Assign Message Type to IDoc Type
    Go to transaction code WE82
    Change the details from Display mode to Change mode
    After selection, the system will give this message “The table is cross-client (see Help for further info)”. Press Enter.
    Click New Entries to create new Message Type.
    Fill details
    Save it and go back
    Go thro' thesre links:-
    http://help.sap.com/saphelp_46c/helpdata/en/dc/6b835943d711d1893e0000e8323c4f/content.htm
    http://help.sap.com/saphelp_erp2005/helpdata/en/0b/2a6620507d11d18ee90000e8366fc2/frameset.htm
    http://www.sappoint.com/presentation.html
    http://www.allsaplinks.com/idoc_search.html
    http://www.sapgenie.com/sapedi/idoc_abap.htm
    http://www.thespot4sap.com/Articles/SAP_ALE_IDOCS.asp
    <b>RFC</b>
    Remote Function Call:
    RFCs are requests that an SAP component sends to invoke functions on remote systems, or calls that remote systems initiate to invoke functions on an SAP component.A process that can accept RFCs from SAP components. This allows SAP components to access functions in external systems. In SAP BC terminology, the process is called a Listener. Listeners are one or more threads on SAP Business Connector that wait for incoming requests from SAP components. Listeners are named and register with an SAP gateway to indicate that they are ready to accept requests. Listeners can accept RFC or tRFC requests.
    Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to transfer ALE Intermediate Documents (IDocs).
    Transactional RFC:
    If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.
    To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.
    Queued RFC:
    When you use transactional RFC, you cannot guarantee the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously.
    RFC is an SAP interface protocol. Based on CPI-C, it considerably simplifies the programming of communication processes between systems.
    RFCs enable you to call and execute predefined functions in a remote system - or even in the same system.
    RFCs manage the communication process, parameter transfer and error handling.
    Have a look at this link.
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf
    http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.
    https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f078394a-4469-2910-c4bf-853c75674694
    Regards
    Ashu

  • ALE/IDOC material

    Hi Experts,
    I m new into ALE/IDOC technology and wht to know in depth and Full fledge. plz suggest me some documents.
    Thanx in advance

    Hi Abdul,
    Check this matter.
    1)EDI
    Electronic Data Interchange
    Cross-company exchange of electronic data (for example business documents) between domestic and international business partners who use a variety of hardware, software, and communication services. The data involved is formatted according to predefined standards. In addition to this, SAP ALE technology is available for data exchange within a company.
    Refer
    http://www.erpgenie.com/sapedi/index.htm
    2) ALE
    A means of creating and operating distributed applications.
    Application Link Enabling (ALE) guarantees a distributed, but integrated, R/3 installation. This involves business-controlled message exchange using consistent data across loosely linked SAP applications.
    Applications are integrated using synchronous and asynchronous communication - not by using a central database.
    ALE consists of the following layers:
    Application services
    Distribution services
    Communication services
    Refer
    http://www.sappoint.com/abap/ale.pdf
    http://www.sappoint.com/abap/ale2.pdf
    Check this link ALE and EDI
    Types of RFC.
    RFC:
    Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.
    Synchronous RFC:
    The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, which means that the systems involved must both be available at the time the call is made.
    Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to transfer ALE Intermediate Documents (IDocs).
    Transactional RFC:
    If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.
    To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.
    Queued RFC:
    When you use transactional RFC, you cannot guarantee the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously
    For more information on RFC, please go through the link.
    http://help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm
    In simple words, ALE is used within the organization and EDI is used betn. the business partners.
    For eg: in ALE, when you want other branches of your company to have the same data as your main branch. You transport the data through ALE methodology.
    Whereas, EDI is used for communication betn ur co. & bank or co. & transport co., etc.
    If the other end does not have SAP, then a middle layer like MERCATOR is used to convert SAP data to non-SAP data and vice-versa.
    The basic difference is that ALE is the SAP technology for communications and you do not have to depend on 3rd party sofywares for the communication. EDI is the technology which requires you to define/create a sub-system that enables data transfers and these subsystems are 3rd party tools.
    THe various types of RFCs used in the technology are
    1. Synchronous RFC
    2. Asynchronous RFC
    3. Transactional RFC (tRFC)
    You can refer these links for ALE and EDI.
    http://www.onestopsap.com/interview-Question/ale/
    http://www.onestopsap.com/interview-Question/edi/
    Hope this resolves your query.
    Reward all the helpful answers.
    Regards

  • ALE/IDOC failure

    Dear all,
    We setup the ALE Idoc for OrgModeler 4.1 which runs fine for initial few minutes and then dies down with following lines
    [Fatel Error] :-1:-1: Premature end of file.
    I have tested the same setup in DEV SAP system and it worked fine with the additional config required in JCo files/versions etc. but the moment I change the connection string to the PRD SAP system we encounter this issue.
    Any clues in this case?
    Best regards.
    Mohammad

    Mohammad.
    Some things to consider...
    1) Have you replicated the precise set-up you have in DEV in PRD?
    i.e. have you worked through each step in the "ALE Setup and Data Extraction" section in the VSN41 Deployment Guide and not received any error message at any stage.  If you are unsure I would suggest working through it again to confirm.
    2) Have you tested your modified connection string in AdminConsole (or did you just change it)?
    3) Does the account you are using for the production system definitely have the appropriate authorisations in place?
    4) Have you tried an out of the box build (minimal configuration - just enough to connect & authenticate) to confirm this isn't somehow related to anything specific to your configured build?
    Regards,
    Stephen.

  • Mail triggering for material received in inbound side using ale/idoc's

    hi,
    i have an issue iam sending a material from sending system to reciving system upto now it is working fine,now the reciving side end user has know that material is received and creted in inbound side..
    here for enduser they doesn't go and check in we02 ..they should initimate externally that material is received  in receiving system .

    thanks for u r reply ,,
    iam new to ale/idoc concept,how can i carete a custom function module ,here what ever the mpping i required i did on sending side ,in inbound side just posting only..
    please can u guide me

  • ALE/IDOC's VS RFC's

    Hi Experts,
    I have a requirement for integration of SAP HR system with the CRM system and pull in few infotypes from HR to CRM. So, please suggest me which approach is the best practice for the integration process. I suggested my client with ALE/IDOC as they have an existing ALE and proposed them creating a new distribution model view for the infotype we need to enhance. But they were asking me to go with RFC approach as they face some issues in data replication. Also i wanna know about the reliability of both the approach after integration. How safe is the implemented approach good in support and future management? Please clarify me on this one and help me out.
    Regards,
    Arunmozhivarman.

    Hi Abhishek,
      This is our scenario. We are doing an integration of SAP HR r/3 system with the CRM system. We need housing information details of the employees which we have in custom infotype 9310 in SAP HR system and we need those details in the CRM system. So am planning out for an ALE/IDOC approach for the integration and gonna  maintain the 9310 details in a custom table. In the CRM system, we gonna build a BOL layer for accessing the 9310 details. Also i'm preparing a HLD for this process. I wanna read and go through few same HLD's before i submit my proposal to my client. Please suggest me and help me out.
    Thanks in advance.
    Regards,
    Arunmozhi.

  • Looking for materials in badi bapi and ale idoc

    dude
        i got materials from <removed by moderator> and other few sites also.i need to know the full structure of bapi badi and ale idoc.
    ppl who are working in these areas pls post materials as well the real time issues facing in their comp.so that i can get a wide knowledge.
    pls post........
    waiting ..
    thnx in advance.
    Edited by: Jan Stallkamp on Aug 18, 2008 8:16 PM

    Check these links before posting any further:
    [Step 1|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] <= this one is important for you dude!
    [Step 2|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] <= see the "Why is no one answering" docs!
    [Step 3|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] <= check your own profile dude!
    [Step 4|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] <= optional, but for a good cause!
    [Step 5|https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/rulesofEngagement] <= not applicable for you yet
    * * * * * Please read the rules if found usefull! * * * * * *

  • Reg:ALE/IDOCS

    Hi Experts,
    I have one doubt in ale/idocs that is , some idocs are accidently posted, how to solve this issue. at the same time how to avoid duplication of idocs. please send the answers.
    Thanks & Regards,
    N.Narasimha Rao.

    I understand what you mean by "Duplicates", but the question that I have to ask is what do you mean by "accidentily posted".
    The key thing to the ALE framework is the proper use of DB transactions.  The updateing of the ALE status and message tables are combined in the same DB transaction as the actual buisness logic updates that are happening in your IDoc processing function.  So what does this mean to you you're asking?  It means that the implimentation of your update logic can sometimes cause the possibility of duplicates.
    Certain types of updates are ones that cause issues, and these would be updates that are beyond your control when it comes to the DB transaction:
    - BDC/Call Transaction - On these they have their own seperate DB transaction, so it is possible that the BDC can sucsesfully post a transaction and then when the logic returns to the IDoc processing function if something causes it to terminate before completing then it is possible that the buisness transaction is complete and your IDoc status has never been updated.  Because the IDoc status has never been updated the same IDoc will get picked up for processing again.
    - Calls to API functions where they contain a commit inside them or an option to include a commit and you don't supress it - Similiar to Call Transaction issues on this one that the buisness transaction can be commited before the framework commits its final status.
    - Multiple transactions - Sometimes it is nesasary to call multiple APIs inside your processing function but they require commits in between them in order to work properly.  An example of this could be first creating a customer master record and then creating a sales order for that customer.  In this case a commit is required inbetween the two calls.  In a case like this it is possible that half of your buisness logic has been executed and commited, the second part hasn't been commited and the framework hasn't commited the status.  The requriment for the commit would be that the customer master API doing the update uses an update task and therefore the actual updates to the DB aren't executed until an explicit commit statement is executed (note also that the ALE framework sets update tasks to local mode so that it doesn't require the use of asynch update processes).
    So, with these above things being issues when it comes to the DB transactions for ALE processing, what can you do to prevent them:
    - For Call transaction issues there isn't much that you can do, becuase the DB transactions is out of your hands.  The only solution I would recommend here is to not use Call Transactions.  It is an old technology anyways and there are much better ways to do it usually by calling APIs.
    - If the API you are calling contains a commit, you should look to see if there is an option for you to turn it off via an input parameter.  If not then you will end up with some of the same issues as Call transaction but there is a technique that you can use to supress duplicates from posting since the DB transaction (unlike in Call Transaction) is actaully the same transaction that was started by the ALE framework, the technique is what I refer to as ALE Stages.
    - If you require multiple API calls which require commits in between them then the solution that I have used many times is what I refer to as ALE Stages.
    So how do you do ALE stages?  The following is an overview of what you'll need to do:
    - Create a new custom table as a copy of the INDX table (data cluster table).  This table is going to be used for two purposes, one is to store information about what has been processed so far and secondly is to handle the passing of transient data if processing is restarted.
    - In your processing function consider it as a number of stages (one for each transaction) and perform the following logic for each stage:
    1) Use the import statement to read in data from the cluster table (Keyed off of the IDoc number).  This contains information about what stages have been completed and also any transient data that has been generated by one stage and needs to be passed to another.  You can use a complex data structre to store all of this information.
    2) If the current stage has already been executed then skip this section of your processing logic.  Otherwise execute it:
    2a) Execute the API call
    2b) Used an export statement to write an updated status to the data cluster table including any transient data that will be required for the next stage.
    2c) Execute a commit
    - After all stages are complete, do a delete on the record in the data cluster table.  Important point though is to not do a commit.  The reason that you don't do a commit is if there is a failure prior to commit inside the ALE framework that update the final IDoc status then you will have lost your stage status information and the entire IDoc would be duplicated again.
    - By doing stages of this type you are creating sub-transactions that if the IDoc fails at any point then when it is reexecuted it will skip the parts that have already been done.
    - The secret to this is that each stage is it's own DB transaction and includes the API call and the update to the stage status table together.  The final deleting of the stage status is linked in with the overall DB transaction done by the ALE framework.
    - In the case where you are using an API that has a commit embbeded inside it that you don't have control over, you can still use stages.  The secret is that you need to update the stage status table prior to the API call.  Even though it is done first it isn't commited until the API executes it's embeded commit.  The only issue with this is that you can't depend on return values from the API as transient data to support the next stage becuase you have no way of writing it to the stage status table as part of the same transaction as the API update.
    This is a failry high-level description of some of the things to look out for and how to handle them.  The use of stages is something I've done a lot and is nice because if implimented properly it will provide a bullet-proof way to ensure that no part of your transaction will be updated twice.  The main issue I find when I see developers try to implimnet this though is that they don't understand completly how DB transactions work and they end up with holes in their logic.
    Hope this helps.  If I've got some time at some point I'll post some specific pieces of code as an example of stages.
    ~Ian
    Edited by: Ian Maxwell on Aug 3, 2008 5:43 PM

Maybe you are looking for