on 04-11-2012 8:39 AM
We are currently looking into When Implementing an Acknowledge IDoc Scenario,
|
Hi,
The RBDSTATE report that triggers ALEAUD messages confirms each IDoc with a separate acknowledgement IDoc - does it meet your requirement? It is just the triggering that is made collectively, as a scheduled background job.
Alternatively, if you need to acknowledge each IDoc at the time of IDoc processing - this cannot be done directly, as IDoc processing is asynchronous by definition. So you can look for some workarounds. I remember writing a simple RFC-enabled function module that was called by Biztalk to "ask" for the processing status of some particular IDoc - you can consider this as one of possible options.
Regards,
Greg
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Greg,
Tnx for the quick reposne.
regarding your quote:
The RBDSTATE report that triggers ALEAUD messages confirms each IDoc with a separate acknowledgement IDoc - does it meet your requirement?
Can you please provide a link for your statment?
As I see \ read it, the RBDSTATE runs periodiclly due to performance reasons.
and therfor collect stasuses of several Idocs and bundle them in a single Ack IDoc.
Therfor in order to close BizTalk Orechstrasion I'll need a single reposne IDoc per inbound IDoc.
regarding you second solution - sounds liek a good workaround.
Did you have any experiance with Async. PROXYs and Applicative Ack from them?
>>> and therfor collect stasuses of several Idocs and bundle them in a single Ack IDoc.
I double checked that and it looks like you are right - one ack IDoc for multiple incoming IDocs... So this might eliminate this solution from the list of acceptable ones.
>>> Did you have any experiance with Async. PROXYs and Applicative Ack from them?
No, I have only created "* to IDoc" and "* to RFC" scenarios with BizTalk. But I believe the general rule can be similar here: some RFC-enabled FM can read the processing status of some incoming message, based on its ID.
You can also think of one more alternative here: you can trigger a "ZALEAUD" IDoc from your custom Proxy implementing class, for that particular message, after it is processed. The difference here is that it is triggered actively from the receiver system, instead of querying ECC from BizTalk. Just to provide you an alternative to consider
Regards,
Greg
User | Count |
---|---|
87 | |
10 | |
10 | |
10 | |
7 | |
6 | |
6 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.