| Author |
Message
|
| arlassen |
 Posted: Mon Mar 06, 2006 6:12 am Post subject: Referencing Message Set Projects from other MSP's |
 |
|
Newbie
Joined: 07 Apr 2005
Posts: 2
|
The Danish OIOXML project (http://www.oio.dk/dataudveksling/danishXMLproject) advises to create one XML schema per global element. Thus we have numerous XML schemas in various namespaces. There is heavily reuse, in particular of so called core XML schemas.
When importing these XML schemas into WMB6 message set projects I run into problems.
Basically I want to reference elements (and types) from one Message Set Project (MSP) in other MSP's. I don't want to have one huge Message Set Project, so I will group the schemas into projects e.g. one MSP for core XML schemas. Thus I need to reference the elements from the core MSP in other MSP's.
The problem is that I can only see the elements from the actual MSP. When trying to import/include other Message Definition Files (i.e. XML schemas) I can only select files from the actual Message Set though I have specified the core MSP as referenced project.
Has anyone a clue to get around this problem? |
|
| Back to top |
|
 |
| kimbert |
| Posted: Mon Mar 06, 2006 7:56 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Thus I need to reference the elements from the core MSP in other MSP's. |
Sorry - not possible. You cannot reference elements from another message set - not even global ones. You can reference messages from another message set ( via their message key ), but I don't think that's what you are trying to do.
You can still avoid having a single huge message set - but you will have to include the core schemas in each and every message set. |
|
| Back to top |
|
|
| arlassen |
| Posted: Tue Mar 14, 2006 3:19 am Post subject: |
|
|
Newbie
Joined: 07 Apr 2005
Posts: 2
|
Thanks kimbert.
I was afraid that would be the answer. It would definitely be an improvement if I could import/include mxsd's from another MSP. Like in a Message Flow Project (MFP), where I can use a subflow from another Message Flow Project.
I have found a little workaround for the problem. If I create a WSDL with the input and output messages for my flows, then the WSDL importer is clever enough to put all the nescessary XML schemas into the MSP. I believe this will give properly sized MSPs. |
|
| Back to top |
|
|
| Sandman |
| Posted: Fri Feb 02, 2007 9:38 am Post subject: Isn't this a rather severe limitation? |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
I was hoping to do the same thing, creating the following [core] message sets:- Message and Command Header
- Party
- Policy
- Claim
- etc.
The reason I want more than one message set for these business model entities is to avoid maintenance contention among developers who would otherwise all be vying to modify (checking out from our repository) the same message set.
Then I wanted to define separate message sets for each use case, which would contain a request/response pair of message defs. That would give us Use Case message sets like:
- Inquiry Party
- Add Party
- Modify Party
- Inquiry Policy
- Add Policy
- Modify Policy
- etc.
The reason I want individual message sets per use case is again to reduce maintenance contention. If we don't expect much concurrent maintenance to each "verb" (Add, Modify, Inquiry) among the same business entity, then we could even combine all flows for that entity into one message set.
Seeing we can't reference message defs in other message sets, is this what you would recommend for us?
- Create the independent message sets for each business model entity group (Party, Policy, etc.) and our Message and Command Header.
- Copy all of the message defs from these 2 message sets into each and every Use Case message set.
Then, for maintenance of Bus. Model message sets:
- Individual, Company, Address, etc. message defs are in the Party message set.
- So checkout/modify that copy.
- Then recopy the modified message def into each and every Use Case message set that uses message defs from the modified message set.
If that might work, it still seems like a mistake-prone process (i.e. what if we forget to copy the modified message def into some Use Case message sets?).
Are there any other simpler ways to keep things segmented to facilitate maintenance without having to resort to this or the "one big message set" (w/ lots of contention)?
Thank you. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 02, 2007 9:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The ACORD data model defines specific messages and transactions.
You should probably follow those instead of trying to roll your own.
You can create specific schemas slimmed down from the overall schema, and then create individual message sets for each transaction from those schemas.
Also, you should examine the impact of changing your version control system to something that doesn't require exclusive checkout.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Sandman |
| Posted: Fri Feb 02, 2007 12:26 pm Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Jeff,
Thanks for the tip on ACORD, but for various reasons (i.e. cost, learning curve, resources, politics, buy-in, etc.), our company has investigated it, and decided not to use it. So we've already modeled our data and transactions as XML schemas (in XMLSpy, not WMB). What we're trying to do now is create MRM and COBOL equivalents.
What exactly do you mean by "You can create specific schemas slimmed down from the overall schema"? If I understand you, wouldn't that defeat the purpose of having the schemas in one place because it would necessitate actual data def changes each time our model changes? What I was originally hoping to do was make the changes in one message set, then simply redeploy all Use Case message sets that used the changed message set.
Seeing that's not possible, I suggested above that we could still make the changes in just one message set, then copy/paste the message def into the affected Use Case message sets.
If I understand what you're suggesting, with each Use Case having its own "slimmed-down" version of the message set, wouldn't we be forced to manually code the changes in each Use Case message def because, in effect, each Use Case message set would have its own custom interface (which is exactly what we're trying to move away from  )??? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 02, 2007 12:29 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I wouldn't make the message definition files the "master" copies.
I would make the XML schemas the master copies. Then when the schema is changed, you can recreate the message defs from the schemas.
This also allows you to use the same schema in multiple message sets.
I just hope your company doesn't have to exchange data with any external parties that require ACORD format.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Feb 05, 2007 6:49 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
The MRM message defs (and COBOL copybooks) are simplified versions of the XML schemas, so re-importing them when they change would not be an option.
As of yet, we have not had to interact w/ ACORD. I agree that that time may come and have tried to champion an effort in that direction. But "adopting standards" for the sake of standards doesn't seem to float very well.
So... given that, can you please offer any advice on which of these approaches might be better?
1. Make the changes in just one message set, then copy/paste the message def into the affected Use Case message sets. This could be error-prone though (i.e. we forget to paste over a necessary use case message set).
2. Keep everything - business model and use case transactions - in one big message set (and perhaps pursue a more flexible change control system)? Are there any runtime/performance issues w/ this?
Thank you. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Feb 05, 2007 6:55 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| 2. Keep everything - business model and use case transactions - in one big message set ... Are there any runtime/performance issues w/ this? |
No |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Feb 05, 2007 6:57 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| The reason I want more than one message set for these business model entities is to avoid maintenance contention among developers who would otherwise all be vying to modify (checking out from our repository) the same message set. |
Why must the change control be applied to entire message sets? What's stopping individual developers from checking out individual message definition files? |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Feb 05, 2007 6:59 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Uhh... good point!  |
|
| Back to top |
|
|
|
|
