on 10-27-2014 10:56 PM
Hi Gurus
Need help with the below design decision:
We have a integration scenario where one system will send down a a XSD to multiple systems (about 10 systems) .
There are multiple nodes in ONE XSD provided by sending application:
SENDER Main XSD:-
<>
<Node_1_Finance>
<Node_2_HR>
<Node_3_CRM>
<Node_3_WM>
<>
Receiver (1):
<>
<Node_1_Finance>
<>
Receiver (2):
<>
<Node_2_HR>
<Node_3_CRM>
<>
Receiver (3):
<>
<Node_2_Finance>
<Node_3_WM>
<>
Please, help wat is the best design approach for ESR Interface Objects; here are some of thoughts :-
1. Sender Side we have External definition which is the main XSD having multiple nodes. So, no issues here to just have one single Sender Service interface.
2. Receiver Side - thinking of multiple GDT's (Global Date Types) created for each area (Example: 1 GDT for replicate the Node_1_Finance, 1 GDT for replicating the Node_2_HR, 1 GDT for replicating Node_3_CRM).
Let me know if the above would be the BEST approach & please provide thoughts on the below:-
1. Based on the above GDT's would it make sense to have just one Receiver Service interface which pretty much looks like the Sender XSD with ALL the GTD's plugged in ?!
-OR-
2. Create individual service interface for each receiver system as shown above (Example: One service interface for Receiver_1 withe just the Finance GDT & one service for Receiver_2 interface for HR & CRM GDT's & so-on ....)
Please, share your thoughts & valuable advice!!
Your help is greatly appreciated!!
Thank you,
Ritu
Hi Ritu,
The best way is to have single interface at sender side with consolidated XSD (with all operation/types). In receiver end you have two option Single interface with all operation or multiple interface.
Advantage of single interface is All operation in one interface
Advantage of multiple interface is easy to design.
I would suggest to use multiple interface at the receiver end, to have independent operation and easy design.
regards,
Harish
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
using multimapping will be complex as you need to take care of 10 target messages mapping. Again if there is not much mapping logic then it makes sense to use multi mapping. having separate mapping will be easier to maintain if you have complex mapping logic.
As mark said you can have condition on receiver determination ,if conditions are straight forward. else you can use enhanced receiver determination.
for multimapping/without multimapping , you need multiple receiver interfaces. with single interface it is not possible.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ritu,
You can have one service interface. coming to message types you can have multiple message types with different names or you can use same name in different namespaces.
Regards,
Naveeb
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ritu,
Adding to the comments above:
Please, help wat is the best design approach for ESR Interface Objects; here are some of thoughts :-
1. Sender Side we have External definition which is the main XSD having multiple nodes. So, no issues here to just have one single Sender Service interface.
Actually in your scenario, it is technically limited to use only ONE service interface because the nodes are inside just ONE root node. For multiple operations to work, the message types would have to be different or they can have the same name but different namespace (target namespace for xsd and wsdl).
2. Receiver Side - thinking of multiple GDT's (Global Date Types) created for each area (Example: 1 GDT for replicate the Node_1_Finance, 1 GDT for replicating the Node_2_HR, 1 GDT for replicating Node_3_CRM).
Let me know if the above would be the BEST approach & please provide thoughts on the below:-
1. Based on the above GDT's would it make sense to have just one Receiver Service interface which pretty much looks like the Sender XSD with ALL the GTD's plugged in ?!
-OR-
2. Create individual service interface for each receiver system as shown above (Example: One service interface for Receiver_1 withe just the Finance GDT & one service for Receiver_2 interface for HR & CRM GDT's & so-on ....)
One receiver interface will also not work because of limitations mentioned above. Just separate the receiver service interfaces and in your interface determination just add conditions to produce the said interfaces via xpath.
Regards,
Mark
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Ritu,
You can use Multiple Operations in Single Service Interface. That way you can keep them in a single binding but make them unique.
You will create 10 different Data Types and Message Types.
Also check Receiver Determination:
Same way keep the conditions for Interface Determination.
For the Mapping:
Regards,
Nabendu.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thank you!! Nabendu
Based your suggestion - we can go with single service interface, supported by multiple message types & data types - AND also single message mapping?!
Also, if there is a single message mapping - will it be easy for support & debug purposes when we have issues ... I am guessing we should still be fine - as the Operation values should segregate it - However, this operation value will not be maintained on the source service interface correct ?! Please, let me know whenever you get a chance. Going through the links you sent as well - May be they will answer my query!!
Thanks again,
Ritu
User | Count |
---|---|
95 | |
11 | |
10 | |
9 | |
9 | |
7 | |
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.