But what I was saying is, for Inbound data from SAP, there are primarily 2 different approaches. Here's how you'd have to go ahead with each of them:
Normal Inbound ALE Adapter:
Create a single Adapter with all types of IDocs that you'd need, configured.
This would create a Message Set with definitions for all the selected IDoc types, which would have to be deployed with the Adapter.
Inbound ALE Adapter in Passthrough mode:
Create a single Adapter of type GenericIDoc.
This would create a very basic Message Set with just one definition - GenericIDocObject.
This parsed message would have a bitstream of the actual IDoc contents which could be passed onto another flow to be parsed.
Thus your Adapter Message Flow need not have the huge Message Set with all IDoc types. Each individual flow for each IDoc type will need a Message Set with definitions for just a single IDoc that is to be processed by the flow.
Thus your Adapter Message Flow need not have the huge Message Set with all IDoc types. Each individual flow for each IDoc type will need a Message Set with definitions for just a single IDoc that is to be processed by the flow.
That is a very good idea... think of what happens if you extend your interfaces to SAP. Redeploying Flows/MessageSets likely requires thorough testing (probably you have automated regressiontests, but still). Also if you would be at the limit (of msg set size) now, what happens if you add to it? So split the different IDOC types into different flows is your suggestion - good design!
Heavily reminds me of the WBI flat file adapter. _________________ Just use REFERENCEs
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum