| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| IIB 10 - Mapping node |
« View previous topic :: View next topic » |
| Author |
Message
|
| Souciance_Rashti |
 Posted: Tue May 09, 2017 5:27 am Post subject: |
 |
|
Newbie
Joined: 09 May 2017
Posts: 7
|
| Wouldn't it be better to stick to language rather than a graphical mapper which may change from version 10 to 12 or get deprecated? You'd be better off in the long run to write the mapping in esql or java. That will make your migration easier as well. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue May 09, 2017 6:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Souciance_Rashti wrote: |
| Wouldn't it be better to stick to language rather than a graphical mapper which may change from version 10 to 12 or get deprecated? |
The mapper in use in v9 & v10 is a strategic IBM product, so it has some life to it. We can also hope that the next product (and I accept there will one day be a next product) will have better migration tools after the complaints migrating to this one.
| Souciance_Rashti wrote: |
| You'd be better off in the long run to write the mapping in esql or java. That will make your migration easier as well. |
I'm forced to disagree with you there. The world's moving away from specialized coders who speak ESQL & Java. We can bemoan that, with some good reason, but the fact remains there's a business need for quickly developed transformations produced by people without deep technical skills. The graphical mapper fills that need. I doubt either ESQL or Java will ever go away as transformational languages, but look at the wider shift away from pure app server Java into JavaScript, node.js and the newer technologies in that space.
Indeed, look and the drag-and-drop nature of Bluemix. Graphical is easier to develop, easier to maintain, and cheaper due to the nature of the staff you can use. It's clearer to the business and adds value.
Just don't use it for everything.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Souciance_Rashti |
| Posted: Tue May 09, 2017 7:08 am Post subject: |
|
|
Newbie
Joined: 09 May 2017
Posts: 7
|
I agree that the mapping tool has improved a lot but I think one bigger aspect is maintainability. It is far easier to maintain and modify esql code than it is to main graphical mappers which in most cases is a complex xml file behind it all.
I agree business requirements has meant a shift from pure code to a more graphical approach but rarely have I found those to work as well as writing your own mapping. Cast Iron or the Sterling Integrator mapper are really bad mappers unless you use them for the standard use case. That's the downside to graphical mappers I guess.
Nodejs and those kind of javascript server side containers and with the advent of docker makes everything easier to work with. It would be awesome to see something like dfdl or MRM in the javascript world. Then things would get really heated up.
Another thing missing I guess is to integration IIB work flow into the general software engineering work to work more test-driven. That would make migration and maintainability easier I would think. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 09, 2017 7:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Souciance_Rashti wrote: |
| I agree that the mapping tool has improved a lot but I think one bigger aspect is maintainability. It is far easier to maintain and modify esql code than it is to main graphical mappers which in most cases is a complex xml file behind it all. |
Why wouldn't you change the map? Why fiddle with the underlying XML?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Souciance_Rashti |
| Posted: Tue May 09, 2017 7:54 am Post subject: |
|
|
Newbie
Joined: 09 May 2017
Posts: 7
|
| Vitor wrote: |
| Souciance_Rashti wrote: |
| I agree that the mapping tool has improved a lot but I think one bigger aspect is maintainability. It is far easier to maintain and modify esql code than it is to main graphical mappers which in most cases is a complex xml file behind it all. |
Why wouldn't you change the map? Why fiddle with the underlying XML? |
If I remember correctly, extract idocs from SAP Adapters resulted in a new map if the idoc structure had changed which made the resusability of the map a bit difficult. You didn't have this problem when writing esql code to parse the idoc. A lot of the times we were forced to migrate away from the mapper to esql for this reason. But this wasy in version 7-8. It could have changed by now.
Sometimes we were forced to fiddle with the xml if we had to redirect the map to another messageset but we didn't want to recreate the map. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue May 09, 2017 10:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Think about merging and comparing code in source control. Now try merging a map... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
