| Author |
Message
|
| deepuu |
 Posted: Wed Apr 16, 2014 12:35 am Post subject: Externalize ESQL mapping in properties file |
 |
|
Newbie
Joined: 27 Dec 2007
Posts: 8
|
hi,
i have a requirement where i want to reuse(without code change or very minimal change) the services developed using ESQL in message broker. Can i externalize the mappings for source(XML SOAP input) and target(TCP/IP outptut) applications and vice versa in a properties file. if yes, how? Someone suggested canonical messgage model but i dont think that is my requirement.
thanks in advance
deepak |
|
| Back to top |
|
 |
| mqsiuser |
| Posted: Wed Apr 16, 2014 1:06 am Post subject: Re: Externalize ESQL mapping in properties file |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
don't buy into stuff that people talk "canonical ...", "reuseable ..."
use ESQL to write a transformation
don't include (or minimize) external dependencies
This also means to not try and put stuff external to your deployment unit
Use stuff that is solidly there like broker nodes and everything you put into your bar-file
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| deepuu |
| Posted: Wed Apr 16, 2014 1:18 am Post subject: Externalize ESQL mapping in properties file |
|
|
Newbie
Joined: 27 Dec 2007
Posts: 8
|
Hi Knight ,
Thanks, I too agree that we should be ding the transformation in the ESQL, but i have a requirment where i want to externalize mapping or tarnsformation code so that i can reuse the service for other countries without rebuilding. I mean, are there pros and cons on why we should not externalize and why we should.
Regards
Deepak |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Apr 16, 2014 2:27 am Post subject: Re: Externalize ESQL mapping in properties file |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
you need a lot of experience and knowledge to do special things
If you don't have that yet (and I think you don't), then do not try to do exotic things.
Do the standard (straight forward) things: ESQL, MRM, XMLNSC, DFDL and use the broker nodes
Externalize the mapping?! This is not a good idea imho
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Apr 16, 2014 3:29 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| are there pros and cons on why we should not externalize and why we should |
A properties file is not the best solution. If you really need to use the same mappings in other products/technologies then WMB and IIB support the use of XSLT.
The need for reuse suggests that there is some duplication in the IT architecture ( two or more systems doing the same job ). Maybe that's a problem that needs to be looked at.
_________________
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: Wed Apr 16, 2014 4:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The mapping is specific to the structure of the two messages it is mapping between.
You can send and receive those two messages over any kinds of transport you want. You can thus "reuse" the same ESQL mapping by using the same code in different message flows.
But the structure of the messages you are mapping between has to be the same.
Otherwise *it's a different mapping*. |
|
| Back to top |
|
|
| deepuu |
| Posted: Wed Apr 16, 2014 6:55 pm Post subject: Externalize ESQL mapping in properties file |
|
|
Newbie
Joined: 27 Dec 2007
Posts: 8
|
Yes, the mapping has to be specific to SOurce/Target applications. If its different, it has to be a different mapping.
But question is can i do it outside esql code? Knight suggests that properties file is not an option. We used to do this with Java so was wondering if we could do something similar with ESQL. so that i can reuse the existing esql without change.just need to change in properties file
Thanks |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Apr 16, 2014 10:01 pm Post subject: Re: Externalize ESQL mapping in properties file |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| deepuu wrote: |
| Knight suggests that properties file is not an option. |
My name is mqsiuser. Knight is my (current) "rank" (based/calculated on the number of posts that I have).
If I were you I'd try to stick to the most standard/straight forward way
Use XSLT if you want to externalize your mapping
It has drawbacks, because mapping is best done in a real programming language
You also require a parser (to create a tree), which means a (shell) script isn't sufficient any more
It (somewhat) means you have to deploy something
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| deepuu |
| Posted: Thu Apr 17, 2014 12:52 am Post subject: Re: Externalize ESQL mapping in properties file |
|
|
Newbie
Joined: 27 Dec 2007
Posts: 8
|
| Well thanks, i will try out and compare the performance to say whether externalizing is the the right way or no. so atleast by looking at performance numbers they can take a call. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Apr 17, 2014 5:24 am Post subject: Re: Externalize ESQL mapping in properties file |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| deepuu wrote: |
Yes, the mapping has to be specific to SOurce/Target applications. If its different, it has to be a different mapping.
But question is can i do it outside esql code? Knight suggests that properties file is not an option. We used to do this with Java so was wondering if we could do something similar with ESQL. so that i can reuse the existing esql without change.just need to change in properties file
Thanks |
No, there is no need for a properties file. You are confusing the mapping with the physical endpoints.
You can reuse the ESQL mapping as many times as you want, by pointing as many different Compute nodes in as many different message flows as you want.
WITHOUT CHANGING THE ESQL.
So you can create a message flow
MQInput->Compute->MQOutput
and another one
SOAPInput->Compute->TCPIPOutput
and another one
FileInput->Compute->SAPRequest
and all of the compute nodes can use *the exact same ESQL file*.
Unless, of course, the messages are different.
Abandon everything you have ever learned about how to build solutions in Java. Do not try to use them in Broker. It's not a Java program, it's not a JEE application. It's a MESSAGE FLOW. It's an entirely different way of thinking about problems. Learn it. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 17, 2014 5:49 am Post subject: Re: Externalize ESQL mapping in properties file |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| deepuu wrote: |
Hi Knight ,
i have a requirment where i want to externalize mapping or tarnsformation code so that i can reuse the service for other countries without rebuilding. I mean, are there pros and cons on why we should not externalize and why we should.
Regards
Deepak |
I am really confused. Are you talking about a message catalog that would have a different insert per language? Mapping is not language dependent. Or rather if it is, in your case, then you're in for quite some headaches...
Mapping content and expansion / transformation should be language agnostic as only computers should ever act on the content... Even the tag names should be language independent...
How, and in which language, you display the message on the target computer is a concern for the application using it... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Apr 17, 2014 10:34 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
@deepuu: I think you need to explain your requirements in much more detail, with an example. fjb_saper thinks you need a way to translate error messages for the users in different countries. I and mqsiuser were both assuming that you wanted a transformation map that you could reuse in a different product.
_________________
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 |
|
|
|
|
