Reg:ALE/IDOCS

Question

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.

Answer 1

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