| Author |
Message
|
| OMG |
 Posted: Mon Feb 20, 2012 2:58 am Post subject: ESQL to Java conversion |
 |
|
Novice
Joined: 20 Feb 2012
Posts: 18
|
URGENT Help Required to convert a piece of ESQL code to Java since I don't know Java at all. Please help me out.
The sample ESQL code is given below.
| Code: |
DECLARE vDrawerNo INTEGER;
IF (refTransaction.ns:DrawerNo IS NOT NULL) THEN
SET vDrawerNo = refTransaction.ns:DrawerNo;
ELSE
SET vDrawerNo = 0;
END IF;
DECLARE Lookup1ID DECIMAL;
DECLARE ValidateOperatorFlag BOOLEAN;
SET ValidateOperatorFlag = FALSE;
DECLARE MessageID CHAR;
SET MessageID = inUsrRef.MessageID;
DECLARE refRetailTransaction REFERENCE TO refTransaction.ns:RetailTransaction;
IF LASTMOVE(refTransaction) THEN
DECLARE retailStoreID, workstationID INTEGER;
SET retailStoreID = CAST(refTransaction.ns:RetailStoreID AS INTEGER);
DECLARE businessDayDate TIMESTAMP;
IF (refTransaction.ns:BusinessDay IS NOT NULL) THEN
SET businessDayDate = refTransaction.ns:BusinessDay;
ELSEIF (refTransaction.ns:BeginDateTime IS NOT NULL) THEN
SET businessDayDate = refTransaction.ns:BeginDateTime;
ELSEIF (refTransaction.ns:EndDateTime IS NOT NULL) THEN
SET businessDayDate = refTransaction.ns:EndDateTime;
END IF;
DECLARE transDate DATE;
SET transDate = CAST(businessDayDate AS DATE);
SET workstationID = CAST(refTransaction.ns:WorkstationID AS INTEGER);
DECLARE lookupCount INT;
DECLARE seq_no ROW;
SET seq_no = PASSTHRU ('SELECT SEQ_ID_TRN.NEXTVAL FROM DUAL');
SET Lookup1ID = seq_no.NEXTVAL;
INSERT INTO Database.{OR_dbSchema}.LKUP_ID_TRN(ID_TRN, AI_TRN, ID_BSN_UN, ID_WS, DC_DY_BSN, ID_SRC_TRN, LU_SRC_LD, LU_SRC_STRG, TY_TRN, QU_TRN_CRT_ATMPT, NM_CRT, TS_CRT, NM_UPDT_LS, TS_UPDT_LS)
VALUES(Lookup1ID, refTransaction.ns:SequenceNumber, retailStoreID, workstationID, businessDayDate, MessageID, inUsrRef.SenderApplicationID, '00', 'RT', 0, appID, CURRENT_TIMESTAMP, appID, CURRENT_TIMESTAMP); |
 |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Mon Feb 20, 2012 3:04 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
My advice would be to tell whoever asked you to do this...
Sorry, I can't do this. I do not know Java.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 20, 2012 3:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Several of the samples that come with broker are implemented in Java. That's a place to start.
There are also several places in the infocenter where examples are listed for both esql and java to do the same tasks.
In general, the complicated part of using Java with message broker is getting the code to access the actual individual elements of the message tree. It's much easier to do this with xpath rather than traversing MbElement, but it can also be a lot slower if you're not careful. |
|
| Back to top |
|
|
| OMG |
| Posted: Wed Feb 22, 2012 1:49 am Post subject: |
|
|
Novice
Joined: 20 Feb 2012
Posts: 18
|
Hi mqjeff
Can you please give me an example of traversing xml tree using xpath in java. Can you give me the equivalent java xpath code of the following examples?
e.g.
DECLARE Usr REFERENCE TO Root.MQRFH2.usr;
DECLARE vTransaction REFERENCE TO refTransaction.ns:Transaction;
DECLARE vHeader REFERENCE TO vTransaction.ns1:Header; |
|
| Back to top |
|
|
| adubya |
| Posted: Wed Feb 22, 2012 1:59 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011
Posts: 377
Location: GU12, UK
|
<is stunned>  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 22, 2012 5:37 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| adubya wrote: |
| <is stunned> |
Welcome to the new world order. Enjoy your stay.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 22, 2012 5:51 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
It does't make sense to change ESQL code to Java.
Why would anyone want to do that ?
Honestly... except for an requirement like "we use java" ! There is no sense in that.
O.k.: I really want someone to come arround with good ideas, why you should might use Java (or even change ESQL to Java) like suggested here - please !
_________________
Just use REFERENCEs
Last edited by mqsiuser on Wed Feb 22, 2012 5:53 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 22, 2012 5:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqsiuser wrote: |
| It does't make sense to change ESQL code to Java. |
It does if you are migrating to Broker v8 Express Edition. |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 22, 2012 5:56 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| mqjeff wrote: |
| It does if you are migrating to Broker v8 Express Edition. |
o.k. ... other/more reasons please.
Note: For stuff you cannot do in ESQL (like getting the hostname) you can call a JAVA-function .... So even when Java gives you more (functionality) then that would/is not a reason to change from ESQL to Java: Just call Java from ESQL.
If you have tranformation code distribute in ESQL and Java (and you want to merge them because both do stuff on the message, and make a copy of the msg before starting) ... no that is unlikely... you would also (likely) decide for ESQL then, hmmm... I have no clue. But there certainly are good reasons.
@OP: pls tell us your reason for your endeavour!
It is much more likely that we/someone here from the forum help(s) you (more intensly) then !!!
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Wed Feb 22, 2012 7:05 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| mqsiuser wrote: |
| It does't make sense to change ESQL code to Java. |
And especially to give the assignment to someone who doesn't know Java.
I've run into teams that have a no ESQL in broker rule because their developers don't know ESQL but they do know Java.
I keep trying to tell them that ESQL can do a lot of stuff very easily and quickly but too many manager types seem to equate ESQL with Java and since their developers don't 'know' ESQL they get scared and forbid it. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 22, 2012 7:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqsiuser wrote: |
| IHonestly... except for an requirement like "we use java" ! There is no sense in that. |
| joebuckeye wrote: |
| I've run into teams that have a no ESQL in broker rule because their developers don't know ESQL but they do know Java. |
There are a lot of sites which have that or a variation of that . It does make sense if you have a significant investment in Java training for the staff and/or the staff rotate round through WMB & non-WMB development (e.g. WESB).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ganesh |
| Posted: Wed Feb 22, 2012 7:38 am Post subject: |
|
|
Master
Joined: 18 Jul 2010
Posts: 294
|
| OMG wrote: |
Hi mqjeff
Can you please give me an example of traversing xml tree using xpath in java. Can you give me the equivalent java xpath code of the following examples?
e.g.
DECLARE Usr REFERENCE TO Root.MQRFH2.usr;
DECLARE vTransaction REFERENCE TO refTransaction.ns:Transaction;
DECLARE vHeader REFERENCE TO vTransaction.ns1:Header; |
There is an example in infocenter which shows how to traverse a tree using JAVA. |
|
| Back to top |
|
|
| inMo |
| Posted: Wed Feb 22, 2012 7:58 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
I've not tested any of this, and am reluctant to suggest trying it, but it appears from your posts that even a small amount of direction is welcomed.
You may want to setup the basics of your JCN to work in terms you are familiar with, aka ESQL terms. Here is a technique you can try to setup an "InputRoot" and "OutputRoot":
| Code: |
MbMessage inMessage = assembly.getMessage();
MbMessage outMessage = new MbMessage();
MbMessageAssembly outAssembly = new MbMessageAssembly(assembly,outMessage);
MbElement inputRoot = inMessage.getRootElement();
MbElement outputRoot = outMessage.getRootElement();
|
|
|
| Back to top |
|
|
| mqsiuser |
| Posted: Wed Feb 22, 2012 8:02 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
| joebuckeye wrote: |
| I've run into teams that have a no ESQL in broker rule because their developers don't know ESQL but they do know Java. |
| Vitor wrote: |
| There are a lot of sites which have that or a variation of that . It does make sense if you have a significant investment in Java training for the staff and/or the staff rotate round through WMB & non-WMB development (e.g. WESB). |
That does not makes sense. If you are so much into Java (...so much that your company would do what joebuckeye says) you would not invest in Broker (but an App-Server). It is impossible to buy Broker for the price it has and then not use ESQL. Guys: You are spending the money for having ESQL !!!
_________________
Just use REFERENCEs |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 22, 2012 8:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
App Server is terrible at acting as an ESB and terrible at providing easy to use message modelling and writing transformations that are tied to a logical structure of data rather than a physical structure.
Buying Broker to use it's full suite of connectivity options and then only using JavaCompute nodes to perform transformations is perfectly reasonable.
Although ESQL is really handy. |
|
| Back to top |
|
|
|
|
