| Author |
Message
|
| rdg |
 Posted: Fri Mar 23, 2018 3:28 am Post subject: IIB Message Modelling Issues (presentation attached) |
 |
|
Newbie
Joined: 28 May 2010
Posts: 9
|
To anyone familiar with Message Broker and Message Sets and thinking about exploring IIB and Message Models, this information might be useful for you.
Also, I'd be interested in hearing any feedback from anyone working with IIB Message Models to-date - have you experienced some of these issues also?
Note: This information is not covering bespoke message formats traditionally modelled in MRM (now modelled in DFDL) specifically but focuses on the use of Message Models for hosting predefined message definitions e.g. import from WSDL, XSD, SAP system etc.
We have been told that all of these concepts / pain points will be true in the upcoming IIB release (App Connect) also.
If you are about to embark on a Message Broker to IIB conversion and you have an eclectic integration estate, I would highly recommend sticking with Message Sets and saving yourself a whole heap of potential trouble with Message Models.
I hope you find this information useful.
http://www.mqseries.net/files/ibm/RSC_IIB_Message_Modelling_Review_v0.6.pdf |
|
| Back to top |
|
 |
| timber |
| Posted: Thu Mar 29, 2018 2:34 am Post subject: |
|
|
Sentinel
Joined: 25 Aug 2015
Posts: 892
|
| Thanks rdg - that's a really valuable piece of analysis. I suggest that you continue to work with IBM to get some of these issues fixed. I've experienced similar pain points, and will do the same. |
|
| Back to top |
|
|
| rdg |
| Posted: Thu Mar 29, 2018 5:57 am Post subject: |
|
|
Newbie
Joined: 28 May 2010
Posts: 9
|
Thank you - please do... I am continuing to pursue on my end.
Current response to-date has been - there are no issues here / nothing to see / working as designed (one of my favourites) / there is value in the way it's been solutioned thus far (though no quotable benefits for us) / and... No one else is complaining!
I thought the fact that the product is tripping over its own limitations in places (one part of the development lab not synchronised with the changes in another) would be enough to admit this needs to be rectified.
Taken it up thus far at architecture level, moving onto offering managers in April. I will post back here on any progress made but not holding up much hope based on IBM reaction to-date. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 29, 2018 6:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 25366
Location: Ohio, USA
|
| rdg wrote: |
| I will post back here on any progress made but not holding up much hope based on IBM reaction to-date. |
I find your lack of faith in @timber disturbing..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| BenThompson |
| Posted: Thu Mar 29, 2018 12:13 pm Post subject: |
|
|
Newbie
Joined: 16 Feb 2011
Posts: 2
|
| Thanks Roberto and Tim. IBM and RS Components have been in touch discussing this great analysis and will continue to do so. |
|
| Back to top |
|
|
| rdg |
| Posted: Mon Jul 09, 2018 7:55 am Post subject: |
|
|
Newbie
Joined: 28 May 2010
Posts: 9
|
Hi Guys, a quick update on this thread.
For Theme (11) / Use Case (11a) "Implement two different SAP Release Versions of the same SAP IDoc" as progressed with support ticket TS000117159 (with help from Ben and David @IBM)...
Workaround available - when customising the target namespace for SAP IDoc discovery scenarios (a workaround already adopted to resolve other IIB Message Model contention issues), further extend the namespace to additionally include a token representing the SAP Release Version of the IDoc e.g. '/46C' or '/702'
This will prevent clashes caused by the unification of Message Model files loaded within an Application, loaded within Static Libraries, at development-time and at deployment-time. |
|
| Back to top |
|
|
| rdg |
| Posted: Mon Jul 09, 2018 8:19 am Post subject: |
|
|
Newbie
Joined: 28 May 2010
Posts: 9
|
For the bulk of the issues faced, which essentially relate to scoping issues with Applications and their Static Library counterparts, IBM are not currently proposing to fix / remove any of these issues but to offer a halfway house instead...
The current proposal is to extend support for Message Sets and SAP Adapters within ACEv11 Shared Libraries (Shared Libraries are not available within IIBv9, and do not currently support Adapters in IIBv10 and ACEv11).
Obviously this doesn't alleviate any of the issues faced if you have a requirement or a desire not to move towards "Shared Libraries", but at least it might be a catalyst to removing some of the current limitations with them.
Our preferred option would be to alleviate the scoping issues faced with Application projects and Static Libraries, as well as better support for Shared Libraries, freeing up Customers to make the correct choice that suits them as to whether they want the additional level of "sharing" that comes with Shared Library implementations.
In my personal opinion, this would lead to a cleaner product offering in the long term, rather than one where "Shared" means more sharing (in change management terms) whilst at the same time, more isolation (in scoping terms).
You might expect Static Libraries to be at least as isolated as Shared Libraries, not less.
As always, grateful if you have any feedback, some practitioners appear to be using older product versions e.g. WMB v7, or are using IIB but not making use of the newer / problematic features e.g. message models, and Libraries. |
|
| Back to top |
|
|
|
|
