| Author |
Message
|
| mqsiuser |
 Posted: Fri Aug 24, 2012 5:33 am Post subject: |
 |
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| whydieanut wrote: |
But to use the Passthrough Adapter, I need to pass data to the Adapter in the Generic IDoc Format.
For this, I need to convert the above XML format message to the SAP ALE IDoc format (using the existing Message Set created while discovering the IDoc Type) which is similar to a CWF message, like below:
(This is what I am unable to achieve with the existing Message Set) |
We typically use 2 different message-sets for parsing-in messages and for writing-out messages.
You want to write out the message with a message-set and this message set was generated for you.
Either it is (just) for parsing in (does that work with that messageset ?) or
Contact the vendor (of the generator) for support (is it IBM ?: Open a PMR) or
You are creating the wrong message tree.
And ofc. take a trace and post it here (in this thread). |
|
| Back to top |
|
 |
| whydieanut |
| Posted: Fri Aug 31, 2012 2:51 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
|
| Back to top |
|
|
| Maximreality |
| Posted: Fri Aug 31, 2012 3:06 am Post subject: |
|
|
Acolyte
Joined: 04 Jun 2004
Posts: 65
Location: Copenhagen
|
When using ALE, your adapter setup in the broker should in generel reflect the setup in the SAP ALE configuration. (so i would recommend that you sit down with your SAP basis guyes and walk through that)
If you use the passthrough functionality, i.e. just passing on a raw idoc, then it doesn't matter how many different idoc types you pass on to that adapter.
That could be that you make a generic distributor of idocs. (that does not require the broker to parse the idoc)
If you use the normal ALE (and need to parse/interpret the idoc) i would recommend having one adapter pr. "Logical message type" in SAP (which is configured in the SAP Partner profiles)
This goes for both inbound and outbound idocs
I would not recommend you to try and save on the number of adapters +messageset deployed, as you over time will loose overview and it will be very difficult to maintain.
/Rasmus |
|
| Back to top |
|
|
| whydieanut |
| Posted: Fri Aug 31, 2012 3:18 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| Maximreality wrote: |
If you use the passthrough functionality, i.e. just passing on a raw idoc, then it doesn't matter how many different idoc types you pass on to that adapter.
That could be that you make a generic distributor of idocs. (that does not require the broker to parse the idoc) |
The problem with using passthrough is that I NEED TO GENERATE THE IDoc from a very basic XML message, and I can't for the life of me, figure out how to convert the XML to the CWF like IDoc format.
I am able to generate the XMLNSC equivalent and send to the normal Outbound Adapter.
| Maximreality wrote: |
If you use the normal ALE (and need to parse/interpret the idoc) i would recommend having one adapter pr. "Logical message type" in SAP (which is configured in the SAP Partner profiles)
This goes for both inbound and outbound idocs |
Initially I wanted to avoid having to have multiple Adapters because maintaining many Adapters seemed like a bother in the long run, especially if some parameter had to be changed for each of the adapters like pointing to a new SAP server, client, etc.
But looking at the amount of time I spend on Iterative Discovery, trying to update my single common adapter, configured for just 3 IDoc types, I am tempted to let each IDoc type have its own adapter.
So coming back to my earlier post, you're suggesting that the one below is a better approach,
(This also saves me from having an extra Common Adapter Gateway Flow.)
| Code: |
Flow1 to create IDOC1 [Adapter1] -> SAP
Flow2 to create IDOC2 [Adapter2] -> SAP
Flow3 to create IDOC3 [Adapter3] -> SAP
Flow4 to create IDOC1 [Adapter1] -> SAP
|
than this, right?
| Code: |
Flow1 to create IDOC1 ->
Flow2 to create IDOC2 -> Intermediate Queue -> Common Flow with Adapter -> SAP
Flow3 to create IDOC3 ->
Flow4 to create IDOC1 ->
|
|
|
| Back to top |
|
|
| Maximreality |
| Posted: Fri Aug 31, 2012 3:46 am Post subject: |
|
|
Acolyte
Joined: 04 Jun 2004
Posts: 65
Location: Copenhagen
|
| whydieanut wrote: |
The problem with using passthrough is that I NEED TO GENERATE THE IDoc from a very basic XML message, and I can't for the life of me, figure out how to convert the XML to the CWF like IDoc format.
I am able to generate the XMLNSC equivalent and send to the normal Outbound Adapter.
|
ok, i would definetly use the normal ALE here, and generate the XMLNSC idoc
| whydieanut wrote: |
Initially I wanted to avoid having to have multiple Adapters because maintaining many Adapters seemed like a bother in the long run, especially if some parameter had to be changed for each of the adapters like pointing to a new SAP server, client, etc.
But looking at the amount of time I spend on Iterative Discovery, trying to update my single common adapter, configured for just 3 IDoc types, I am tempted to let each IDoc type have its own adapter.
|
The chance that your SAP server or client number etc. changes is very small in your production environment. And all of those things can anyway be configured using "configurable properties" on the broker (which i would recommend using if you are not already using them).
It is more likely that the structure of the idoc changes over time, and when you have multiple idoc types in one messageset this will give you a headache.
| whydieanut wrote: |
So coming back to my earlier post, you're suggesting that the one below is a better approach,
(This also saves me from having an extra Common Adapter Gateway Flow.)
| Code: |
Flow1 to create IDOC1 [Adapter1] -> SAP
Flow2 to create IDOC2 [Adapter2] -> SAP
Flow3 to create IDOC3 [Adapter3] -> SAP
Flow4 to create IDOC1 [Adapter1] -> SAP
|
than this, right?
|
Yes, i would go for a solution where you have one adapter pr. logical message type in SAP, both inbound and outbound. (you can view the logical messagse types configured in transaction WE20 under Partner Type LS)
SAP Inbound you can have multiple flows using the same RFC destination. ie. many flows sending idocs of the same logical type
| Code: |
MSGFLOW1 -> Adapter1 -> SAP RFC destination1 -> SAP logical message1
MSGFLOW2 -> Adapter1 -> SAP RFC destination1 -> SAP logical message1 |
SAP Outbound you can only have one adapter pr. RFC program ID
| Code: |
| SAP logical message3 -> SAP RFC destination3 -> Adapter3 -> MSGFLOW3 |
/Rasmus |
|
| Back to top |
|
|
| whydieanut |
| Posted: Fri Aug 31, 2012 3:59 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| Maximreality wrote: |
The chance that your SAP server or client number etc. changes is very small in your production environment. And all of those things can anyway be configured using "configurable properties" on the broker (which i would recommend using if you are not already using them).
It is more likely that the structure of the idoc changes over time, and when you have multiple idoc types in one messageset this will give you a headache.
|
Right said!
Pros and Cons for both approaches, need to find a balance!
| Maximreality wrote: |
SAP Outbound you can only have one adapter pr. RFC program ID
Code:
SAP logical message3 -> SAP RFC destination3 -> Adapter3 -> MSGFLOW3
|
This is taken care of by the Passthrough Inbound Adapter which is a breeze!
( If only I could get it to work the other way around too :-/ ) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Sep 01, 2012 12:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| whydieanut wrote: |
The problem with using passthrough is that I NEED TO GENERATE THE IDoc from a very basic XML message, and I can't for the life of me, figure out how to convert the XML to the CWF like IDoc format.
I am able to generate the XMLNSC equivalent and send to the normal Outbound Adapter. |
Think of it as if you need to generate a cobol copy book type message.
The difference is that the IDOC structure does not specify the filler at the end of the segment. Typical segment length (EDI_DD40) is 1063 bytes.
63 bytes form the identification part and 1000 bytes are devoted to the segment data. The segment data is defined by the segment name in the identification part....
An SAP IDOC is formed of one EDI_DC40 control segment (different lenght and composition) and multiple EDI_DD40 segments.
Essential fields in the EDI_DC40 define the IDOC and the sequence and content of the various EDI_DD40 segments as defined in the SAP EDI subsystem.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| whydieanut |
| Posted: Sun Sep 02, 2012 9:54 pm Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| fjb_saper wrote: |
Think of it as if you need to generate a cobol copy book type message.
The difference is that the IDOC structure does not specify the filler at the end of the segment. Typical segment length (EDI_DD40) is 1063 bytes.
63 bytes form the identification part and 1000 bytes are devoted to the segment data. The segment data is defined by the segment name in the identification part....
An SAP IDOC is formed of one EDI_DC40 control segment (different lenght and composition) and multiple EDI_DD40 segments.
Essential fields in the EDI_DC40 define the IDOC and the sequence and content of the various EDI_DD40 segments as defined in the SAP EDI subsystem. |
I am aware of this. But I don't want to have to manually create another message set for this.
My premise is that, in case of the normal Inbound ALE Adapter, the adapter creation wizard creates a Message Set for me that can parse the ALE IDoc (CWF like) message into a logical tree. So why isn't the normal Outbound ALE Adapter capable of taking a logical message tree and converting it into the SAP ALE IDoc format bitstream with the Message Set created for the Outbound Adapter? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 03, 2012 11:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| whydieanut wrote: |
I am aware of this. But I don't want to have to manually create another message set for this.
My premise is that, in case of the normal Inbound ALE Adapter, the adapter creation wizard creates a Message Set for me that can parse the ALE IDoc (CWF like) message into a logical tree. So why isn't the normal Outbound ALE Adapter capable of taking a logical message tree and converting it into the SAP ALE IDoc format bitstream with the Message Set created for the Outbound Adapter? |
It can but this would be defeating the purpose of a generic adapter. The generic adapter would not be aware of the specific structure of the IDOC, and take in either only EDI_DC40 and EDI_DD40 records or just the BLOB representing them...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| whydieanut |
| Posted: Tue Sep 04, 2012 12:20 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| fjb_saper wrote: |
| It can but this would be defeating the purpose of a generic adapter. The generic adapter would not be aware of the specific structure of the IDOC, and take in either only EDI_DC40 and EDI_DD40 records or just the BLOB representing them... |
Okay, agreed the Generic Adapter would take in only the BLOB representation of the IDoc.
Now how can I generate this BLOB from a normal, non IDoc, XML message?
What I had been doing was taking this XML input and transforming it into the SAP ALE IDoc logical structure (with all the relevant records and segments like the Control Record [EDI_DC40] and Data Record [EDI_DD40]) and then trying to output it via an MQ Output node by also changing the physical format to 'SAP ALE IDoc' (from the existing XMLNSC format)
I'd been doing this because it seemed analogous to what happens in case of the Generic Inbound Adapter, where the the Generic Adapter flow (one from the built in pattern) took the IDoc stream data out of the Generic IDoc received by the Adapter and converted it to BLOB and sent this to a second, IDoc type specific flow. This second flow had an MQ Input node with a Message Set, generated by a normal ALE Adapter, with the following properties:
Message Domain: DataObject : For data from WebSphere Adapters, CORBA and Database records
Message Set: <Msg Set created by the Adapter creation wizard for this particular IDoc type>
Message Type: <Msg Type created by the Adapter creation wizard for this particular IDoc type>
Message Format: SAP ALE IDoc (the other option in the drop down being XML)
This flow would then take the CWF like BLOB output by the first flow and parse it into a Logical Tree.
So my question is, in case of the normal Outbound ALE Adapter, will the Msg Set generated by the Adapter creation wizard for a specific IDoc be capable of taking such a logical tree (IDoc representation) and output a CWF like IDoc format message?
If yes, this output would become the input for my Generic IDoc flow, which would wrap this input with the SAP Generic IDoc envelop like below:
<NS1:SapGenericIDocObject xmlns:NS1="http://www.ibm.com/xmlns/prod/websphere/j2ca/sap/sapgenericidocobject">
<SAPTransactionID>AC150C6908E04E803C2E062D</SAPTransactionID>
<IDocStreamData>
... (The hex representation of the input to this flow)
</IDocStreamData>
<IDocType>CREMAEXT</IDocType>
</NS1:SapGenericIDocObject> |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Sep 04, 2012 9:51 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That's the way it's supposed to work. But you need to make sure your output is binary (CWF) and the IDoc is generated correctly (i.e. the filler space is respected at the end of the sdata segment)
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| whydieanut |
| Posted: Thu Oct 11, 2012 10:32 pm Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
| Maximreality wrote: |
The chance that your SAP server or client number etc. changes is very small in your production environment. And all of those things can anyway be configured using "configurable properties" on the broker (which i would recommend using if you are not already using them).
It is more likely that the structure of the idoc changes over time, and when you have multiple idoc types in one messageset this will give you a headache.
| whydieanut wrote: |
So coming back to my earlier post, you're suggesting that the one below is a better approach,
(This also saves me from having an extra Common Adapter Gateway Flow.)
| Code: |
Flow1 to create IDOC1 [Adapter1] -> SAP
Flow2 to create IDOC2 [Adapter2] -> SAP
Flow3 to create IDOC3 [Adapter3] -> SAP
Flow4 to create IDOC1 [Adapter1] -> SAP
|
than this, right?
|
Yes, i would go for a solution where you have one adapter pr. logical message type in SAP, both inbound and outbound. (you can view the logical messagse types configured in transaction WE20 under Partner Type LS)
/Rasmus |
Coming back to the earlier question,
I am now going with the one Adapter per IDoc type approach.
But can't decide on whether to include the Adapter in the individual flows directly or have a separate secondary flow for each Adapter.
Basically what I am thinking about is, is it a better idea to include the Adapter directly in each message flow (connecting to the source system) or is better to abstract the Adapter via an intermediary Queue, and let each of the source flows convert the input to IDocs and put them in respective intermediary queues, from which dedicated Adapter flows pick up the IDocs and send them to SAP, without any further processing.
Option 1: Single Flow
| Code: |
System A
[Input XML1] -> [Transform to IDoc1] -> [IDoc1 Adapter] -> SAP
System A
[Input XML2] -> [Transform to IDoc2] -> [IDoc2 Adapter] -> SAP
System B
[Input XML1] -> [Transform to IDoc1] -> [IDoc1 Adapter] -> SAP
|
Option 2: Two Flows
| Code: |
System A
<-------------- flow 1 -------------------> <-------- flow 2 -------->
[Input XML1] -> [Transform to IDoc1] -> IDoc1 Q -> [IDoc1 Adapter] -> SAP
[Input XML2] -> [Transform to IDoc2] -> IDoc2 Q -> [IDoc2 Adapter] -> SAP
System B
<-------------- flow 1 -------------------> <-------- flow 2 -------->
[Input XML1] -> [Transform to IDoc1] -> IDoc1 Q -> [IDoc1 Adapter] -> SAP
|
|
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Oct 11, 2012 11:59 pm Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi,
One thing that you should take account of is how your process needs to react on failures and does the process originator need the feedback that process reached or not the end point(s).
--
Marko |
|
| Back to top |
|
|
| whydieanut |
| Posted: Fri Oct 12, 2012 12:20 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
At the moment, there is no automated response sent to any of the source systems.
The only time the secondary Adapter flows would fail would be in case of any connectivity issues with SAP, in which case, the IDoc would be put into an error queue, which can be later manually reprocessed (by passing it again through the secondary Adapter flow).
Anything wrong with such an approach?
At the moment, there are far too many changes coming in to the IDoc formats and this is making me uncomfortable having to keep the Adapter (which gets impacted with the IDoc changes) in multiple primary flows (for different source systems sending the same kind of IDoc data). |
|
| Back to top |
|
|
| whydieanut |
| Posted: Fri Oct 12, 2012 12:23 am Post subject: |
|
|
Disciple
Joined: 02 Apr 2010
Posts: 186
|
Another option I was considering is, to have the Adapters to go into specific sub flows, which will be added to any flow that requires that kind of IDoc.
What opinions do you have about this? |
|
| Back to top |
|
|
|
|
