ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexWebSphere Message Broker SupportIIB 10 - Mapping node

Post new topicReply to topic Goto page Previous  1, 2, 3
IIB 10 - Mapping node View previous topic :: View next topic
Author Message
Souciance_Rashti
PostPosted: Tue May 09, 2017 5:27 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue May 09, 2017 6:43 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24614
Location: Ohio, 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
View user's profile Send private message
Souciance_Rashti
PostPosted: Tue May 09, 2017 7:08 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Tue May 09, 2017 7:20 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24614
Location: Ohio, 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
View user's profile Send private message
Souciance_Rashti
PostPosted: Tue May 09, 2017 7:54 am Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Tue May 09, 2017 10:58 am Post subject: Reply with quote

Grand Poobah

Joined: 18 Nov 2003
Posts: 19400
Location: LI,NY

Think about merging and comparing code in source control. Now try merging a map...
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Goto page Previous  1, 2, 3 Page 3 of 3

MQSeries.net Forum IndexWebSphere Message Broker SupportIIB 10 - Mapping node
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.