tag:blogger.com,1999:blog-3078460769226170088.post1333206895079840626..comments2024-02-16T03:47:56.872-08:00Comments on Kent Weare's Integration Blog: Reprocessing SAP IDocs through BizTalk Server using WE19Kent Wearehttp://www.blogger.com/profile/12128408181333089696noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-3078460769226170088.post-58853292284679484872012-07-07T14:07:11.099-07:002012-07-07T14:07:11.099-07:00Hi M.P.
I believe I understand what you are tryin...Hi M.P.<br /><br />I believe I understand what you are trying to achieve. I don't think there is a really good way to do this.<br /><br />We do have a similar situation where we need to take materials from SAP and then update CRM. So for us we check to see if the material exists within CRM, if it doesn't we insert if it does then we will update. Now in this situation, CRM provides us with interfaces to do all of these things.<br /><br />Another option is to store the data yourself is some sort of SQL respository and manage this yourself. I don't like this idea though as I believe that managing deltas should not happen within Middleware.<br /><br />Another option would be to modify the SAP IDoc to have a modification timestamp on the various data elements. I would imagine this would also be very tedious but it is an option.<br /><br />KentKent Wearehttps://www.blogger.com/profile/12128408181333089696noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-57975778314974826522012-07-07T06:52:27.681-07:002012-07-07T06:52:27.681-07:00Hi Kent.
Thanks for all the excellent blog posts ...Hi Kent.<br /><br />Thanks for all the excellent blog posts you have provided.<br /><br />I have a question that ties in with this old blog post of yours.<br /><br />I want to update 3rd party systems (downstream) with person/user information from SAP HR.<br /><br />I have created an integration between SAP HR and Biztalk Server 2010, using the WCF SAP adapter v2010. On the SAP side SAP consultants have created a custom IDOC based on the HRMD_A07 message type, and activated change pointers for the new message type so we will receive (deltas) an IDOC when a change has occurred for users (ex: mobile number changed, email updated, new location, new hiring etc.).<br /><br />The challenge is to determine from the received IDOC what really changed...because it contains a lot of information and info types, despite the filters applied on the SAP side. It is hard to determine what have changed and where from the structure of the received IDOCs.<br /><br />Since you have quite a lot of experience integrating with SAP, maybe you have some suggestion on how to do this or could direct me in the right direction on what to look for or how??<br /><br />Thanks in advance.<br /><br />-M.PUnknownhttps://www.blogger.com/profile/01974339755741916911noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-80098948689830333432010-09-22T13:40:19.653-07:002010-09-22T13:40:19.653-07:00Hi again
coming back on that e2e monitoring (and w...Hi again<br />coming back on that e2e monitoring (and with a simple question).<br />I used this post: http://www.wmusers.com/forum/archive/index.php/t-7341.html to find out that there is just a RFC named INBOUND_IDOCS_FOR_TID (yuppi) in SAP. Well, it does not work with SAP adapter (weee) because of the nested tables feature that it is using. No problem, my SAP colleague wrote the RFC selecting the right stuff (for me TID and DOCNUM) from the edids table and the work is done. One more small detail, he had to add the magic word SINGLE in the beginning of the select clause just to omit this ugly issue with nested tables (good we have one docnum per tid). Right, now only schedule sending of ALEAUD idocs to BizTalk (they contain DOCNUM together with the status code) and the works is done. I hope it helps someone crawling like me last days through the blogs.<br />Now for the question, I haven't worked with orchestrations much, so it comes - should we have one ProgId for the listener port which is starting an orchestration? I know, using CBR is better, one port with one ProgID is enough but just theoretically, is it one to one (rec port with ProgID for orchestration)?<br />Kind regards<br />MaciekUnknownhttps://www.blogger.com/profile/02034048411623086150noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-13317547831513947162010-09-07T00:33:56.825-07:002010-09-07T00:33:56.825-07:00Thank you for your answer.
We are planning to use...Thank you for your answer.<br /><br />We are planning to use only BizTalk for routing (so no SAP workflows) in the design of the solution. Also going asynchrnonously seems to be a better idea having in mind that SAP does not always process the idocs when they are received and there would be SOME of them to process (hospital implementation of SAP).<br /><br />What we're trying to achieve is e2e monitoring with BAM, meaning we use BAM API for monitoring in the receiving location, mapping and then SAP send adapter. To include the SAP end in the monitoring we'd like to see if the result of processing in SAP was good (53) and if not alert on that.<br /><br />If you other ways of achieving that, please let me know, I'll let you know if I get it solved.<br /><br />Best<br />MaciekUnknownhttps://www.blogger.com/profile/02034048411623086150noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-24659763429237495282010-08-20T06:05:00.909-07:002010-08-20T06:05:00.909-07:00Hi Maciej
Interesting problem. We have not tried...Hi Maciej<br /><br />Interesting problem. We have not tried to implement this before, but I understand what you are trying to achieve. Since IDOC processing is an Asynchronous event, would a BAPI/RFC call be an option? This way your interface would be a syncrounous event and BizTalk would have an indication that SAP successfully received/processed the message.<br /><br />Another question is what is BizTalk suppose to do when the status is not 53? Wouldn't this be a problem better solved through SAP Workflow or sending an indication to a person's SAP Inbox. I am not questioning your design, but curious to know what BizTalk would do in this situation since SAP would have a better idea why an IDOC didn't process. If you do find a solution, please post back here as I am interested as well.Kent Wearehttps://www.blogger.com/profile/12128408181333089696noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-40491596574179351502010-08-19T06:37:07.360-07:002010-08-19T06:37:07.360-07:00Hello Kent
Have you experience with grabbing the ...Hello Kent<br /><br />Have you experience with grabbing the status of processing an idoc that you send to SAP? We send an idoc with no DOCNUM field filled in and then would really like to know (back in BizTalk) if it was processed successfully (status=53).<br />I know there is ALEAUD idoc type that can be scheduled on SAP side and periodically would inform about the statuses but the issue is that we don't know the DOCNUM when sending the idoc but it is the only field to get correlation on when the ALEAUD idoc is sent down to BizTalk. <br />Please let me know as it is a show stopper for us now and mr google does not seem to know that...<br />Cheers<br />MaciekUnknownhttps://www.blogger.com/profile/02034048411623086150noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-48993053917079861952010-06-22T06:13:46.778-07:002010-06-22T06:13:46.778-07:00Hi Peter,
Thanks for the comment. In terms of &qu...Hi Peter,<br /><br />Thanks for the comment. In terms of "Reprocessing" I think it depends what context you are considering. In my case, the IDoc is being reprocessed by BizTalk and not SAP. I am not looking to have the IDOC reprocessed by SAP, but rather it gives developers an easy way to resend IDocs to BizTalk which allows them to test without the envolvement of SMEs creating new IDOCS.<br />Thanks for your suggestions regarding having SAP reprocess IDOCs.<br /><br />KentKent Wearehttps://www.blogger.com/profile/12128408181333089696noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-2433205551927555652010-06-22T00:40:42.641-07:002010-06-22T00:40:42.641-07:00Reprocessing via WE19 is nothing more then creatin...Reprocessing via WE19 is nothing more then creating a copy of the initial idoc. The initial idoc is not reprocessed, it is the copy whih is send instead. The initial idoc will stay on status 03 in SAP (tx WE05).<br />To actually reprocess the initial idoc itself you can use tx SM58. Select an idoc and go via the menu edit to Execute LUW, or to mass execute (via the background) choose Execute LUWs.<br />Now no copy will be made, but the initial idoc is reprocessed and if processing goes fine the status of this idoc is set to 12 (in case a status idoc is send back by biztalk)<br /><br />I hope this is useful infoPeter Oosterlinghttps://www.blogger.com/profile/14748818869857208379noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-3258253308601014802010-01-09T09:34:59.545-08:002010-01-09T09:34:59.545-08:00Hi Christophe,
I have dealt with ordered delivery...Hi Christophe,<br /><br />I have dealt with ordered delivery inbound into SAP but not outbound. For inbound we are receiving a messages from a MQ Series queue, marking the receive port for order delivery, using a Singleton orchestration and then marking the send port for order delivery.<br /><br />For your scenario I am not 100% sure but I think SAP will need to implement a QRFC interface which will inforce ordered delivery coming out of SAP. Sorry for the lack of details but I would start looking at QRFC.Kent Wearehttps://www.blogger.com/profile/12128408181333089696noreply@blogger.comtag:blogger.com,1999:blog-3078460769226170088.post-78815930531622623582010-01-05T01:10:54.289-08:002010-01-05T01:10:54.289-08:00Hi Kent,
I'm also working on SAP and BizTalk ...Hi Kent,<br /><br />I'm also working on SAP and BizTalk 2009 communication, thanks for your post.<br /><br />Have you already experienced ordered delivery with WCF-SAP Adapter ? How to ensure this Adapter stores IDocs messages into MessageBox in the same order SAP provides them ?<br /><br /><br />Thanks for your answer.<br />ChristopheAnonymoushttps://www.blogger.com/profile/05430507941641706507noreply@blogger.com