| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| IIB9: Message Model , Bad legacy schema |
« View previous topic :: View next topic » |
| Author |
Message
|
| akil |
 Posted: Sat May 16, 2015 5:33 am Post subject: IIB9: Message Model , Bad legacy schema |
 |
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
So I have a couple of legacy systems that does not use namespaces , so all elements are in the global namespace. As luck would have it, some elements have the same name (but different data-types), so I am kind of stuck..
I was thinking of assigning namespaces in the workspace to the 2 systems, doing the complete processing with namespaces, and just before the request is sent out (before the HTTPRequest Node), I write some code to strip off the namespace from the message that is about to go out - Not an elegant solution, but I can't think of anything else ..
_________________
Regards |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon May 18, 2015 4:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You have the two models in separate applications and separate projects, right?
Then I don't *think* they should not be deployable. Models in one application shouldn't interfere with another.
If nothing else, you can use an intermediate transport to invoke a separate application that does the HTTPRequest for each model. |
|
| Back to top |
|
|
| akil |
| Posted: Mon May 18, 2015 10:07 am Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
Hi
As luck would have it I have to create a service ( integration service project ) that interacts with both of these systems..
_________________
Regards |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 18, 2015 10:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| akil wrote: |
Hi
As luck would have it I have to create a service ( integration service project ) that interacts with both of these systems.. |
You can still send messages in the input format of the service into separate applications (using MQ or etc) to secondary applications.
It's probably easier to build the models with the temporary namespaces and then remove them as needed, like you said...
But there are options that don't require you to mess with the original schemas.
 |
|
| Back to top |
|
|
| stoney |
| Posted: Mon May 18, 2015 10:23 am Post subject: |
|
|
Centurion
Joined: 03 Apr 2013
Posts: 140
|
| akil wrote: |
Hi
As luck would have it I have to create a service ( integration service project ) that interacts with both of these systems.. |
Hi,
I know you mention IIBv9 in the subject, but is IIBv10 an option?
In IIBv10 you can use shared libraries - one shared library for each set of schemas - and use both of those shared libraries from a single integration service, application, or REST API.
Cheers,
Simon |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 18, 2015 10:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| stoney wrote: |
| akil wrote: |
Hi
As luck would have it I have to create a service ( integration service project ) that interacts with both of these systems.. |
Hi,
I know you mention IIBv9 in the subject, but is IIBv10 an option?
In IIBv10 you can use shared libraries - one shared library for each set of schemas - and use both of those shared libraries from a single integration service, application, or REST API. |
Does that solve the problem of two shared libraries having objects in the same namespace with differing meanings?
Last edited by mqjeff on Mon May 18, 2015 12:08 pm; edited 1 time in total |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon May 18, 2015 11:49 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Unfortunately, this problem is quite common in IIBv9. Not just with badly-written legacy apps either. Name clashes are reported when one message flow needs to work with two different WSDLs, and the two WSDLs pull in a global element from a common xsd.
I am normally the last person to suggest using a message set in a ( new ) v9 message flow. However, in this case the simplest solution is probably:
- Create two message sets - one for each message. You will not get errors if the clashing QNames are in different message sets.
- Configure your SOAPxxx nodes using the message sets.
As stoney rightly points out, IIBv10 offers shared libraries, and they are a great solution to this problem ( and a few other problems too ).
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 18, 2015 12:09 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| kimbert wrote: |
| As stoney rightly points out, IIBv10 offers shared libraries, and they are a great solution to this problem ( and a few other problems too ). |
So two shared libraries can contain duplicate QNames? Or the same shared library can? |
|
| Back to top |
|
|
| stoney |
| Posted: Mon May 18, 2015 12:52 pm Post subject: |
|
|
Centurion
Joined: 03 Apr 2013
Posts: 140
|
| mqjeff wrote: |
| kimbert wrote: |
| As stoney rightly points out, IIBv10 offers shared libraries, and they are a great solution to this problem ( and a few other problems too ). |
So two shared libraries can contain duplicate QNames? Or the same shared library can? |
Two shared libraries can contain duplicate QNames, as long as they do not reference each other.
For example:
sharedLibrary1 contains a defintion of ns1:Employee.
sharedLibrary2 contains a different, clashing definition of ns1:Employee.
sharedLibraryA contains a definition of ns1:Customer.
All three shared libraries can be deployed to the same integration server without issue.
Each shared library has a message model (a set of schemas) that can be used with the XMLNSC validator, DFDL parser, graphical mapper, etc.
The message model for a shared library contains all schemas in that shared library, and all of the schemas in any other shared libraries referenced by that shared library - as long as there are no QName clashes.
So, sharedLibrary1 can reference sharedLibraryA. As a result, the message model for sharedLibrary1 contains both ns1:Employee and ns1:Customer.
However, sharedLibrary1 cannot reference sharedLibrary2 - due to the clashing definition of ns1:Employee. You will get a toolkit error and deployment failure if you try to do this.
Additionally, each application (and the same applies for integration services and REST APIs) has its own message model, as per V9 and before.
The message model for an application contains all of the schemas from that application and any included static (old style) libraries. It does not include any schemas from any shared libraries referenced by that application.
This means that you can have an application which has its own clashing definition of ns1:Employee.
That application can reference any of the above shared libraries, and it can also reference both sharedLibrary1 and sharedLibrary2, even though they contain clashing definitions of ns1:Employee.
You can choose which set of schemas to use for the XMLNSC and DFDL domains by altering the message model field of the parser options (it's the old message set field, just re-purposed).
You use "" (blank) to select the message model for the current container, and "{sharedLibrary1}" to select the message model for a referenced shared library.
The current container is the application or shared library that contains the flow or subflow where the parser is being created.
You can also use clashing definitions of the same QName from the graphical mapper.
For example, you can create a map in the application to map between the clashing definitions of ns1:Employee in sharedLibrary1 and sharedLibrary2 - useful perhaps if you need to map between V1 and V2 of the same schema.
You simply choose which version you want when specifying the inputs and outputs for the map.
It's important to note that in a schema in a shared library, you can import/include other schemas from other shared libraries referenced by that shared library.
However, from a schema in an application, you cannot import/include other schemas from any shared libraries referenced by that applications.
Schemas in applications are completly isolated from schemas in shared libraries. |
|
| Back to top |
|
|
| akil |
| Posted: Mon May 18, 2015 8:37 pm Post subject: |
|
|
Partisan
Joined: 27 May 2014
Posts: 338
Location: Mumbai
|
IIBv10 is definitely an option, we have around 30 services that are on v9, I've not yet started on the migration, but that's definitely in the short term for the JSON modelling, the Environment in the Map and now one more (shared libraries)..
Summarising the 3 options
separate flow with an intermediate transport : a little more effort, but complete isolation
message sets : looks clean, but is a deprecated feature (needs to be turned on in the developer toolkit )
use temporary namespaces : corrupts the provided schemas
IIBv10 : shared libraries
Will try out the 3 and post results, inclined towards the third option primarily because it leverages what I already know (message models)
_________________
Regards |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
