| Author |
Message
|
| pavel112233 |
 Posted: Tue Oct 04, 2016 11:50 am Post subject: |
 |
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
| mqjeff wrote: |
A minor point is that you are calling both CopyMessageHeaders and CopyEntireMessage.
It's not an issue, the CopyEntireMessage will recopy all the things CopyMessageHeaders did.
It looks like you're trying to insert a value into a DB. Presumably at this point you're able to get the right value to send to the DB...
Regardless, your flow still seems not to work? So can you show us what happens - the error or etc. |
what happens is that the result of insert is null in first column when I expect "1":
INSERT INTO Database.test1 (ID, val) VALUES (InputRoot.XMLNSC.TestRoot.a, 2)
------------
select * from test1
null | 2 |
|
| Back to top |
|
 |
| timber |
| Posted: Tue Oct 04, 2016 11:55 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Your ESQL is wrong. The root tag is TestRoot (as clearly shown in the Trace node output that you posted) so the ESQL field reference for accessing /TestRoot/a is
| Code: |
| InputRoot.XMLNSC.TestRoot.a |
For the record, <a>1</a> is a tag and not an attribute. I'm not being picky; in this industry names really do matter. You're lucky that somebdoy didn't start recommending the use of XMLNSC.Attribute in your ESQL field reference.
Also, and before somebody like rekarm01 pops up and points it out...the value '1' is not CData. It is PCData (Parsed Character Data). CData is data that is wrapped in a <[[CDATA[ ]]> section.
[edit] and it's not mixed content either. 'Mixed content' is text data that occurs before, between or after the child tags in the content of an enclosing tag.
Last edited by timber on Tue Oct 04, 2016 12:00 pm; edited 1 time in total |
|
| Back to top |
|
|
| pavel112233 |
| Posted: Tue Oct 04, 2016 11:55 am Post subject: |
|
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
and when I try some properties of the message it works ok. the problem is in the BODY
INSERT INTO Database.test1 (ID, val) VALUES (InputRoot.Properties.Encoding, 2)
select * from test1
273 | 2 |
|
| Back to top |
|
|
| timber |
| Posted: Tue Oct 04, 2016 11:58 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
I take back my comment about your ESQL field reference...you're already doing what I recommended.
Surely the next step is a user trace. That should provide some useful insight into what's going on in your flow. I would not try anything else until I had done that. |
|
| Back to top |
|
|
| pavel112233 |
| Posted: Tue Oct 04, 2016 12:01 pm Post subject: |
|
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
| timber wrote: |
Your ESQL is wrong. The root tag is TestRoot (as clearly shown in the Trace node output that you posted) so the ESQL field reference for accessing /TestRoot/a is
| Code: |
| InputRoot.XMLNSC.TestRoot.a |
For the record, <a>1</a> is a tag and not an attribute.
|
thank you for the advise but as I mentioned earlier it doesn't work as well
<TestRoot><a>1</a></TestRoot> + InputRoot.XMLNSC.TestRoot.a
=
null | 2
Error time: 2016-10-04 21:01:20.324204
Exception:
( ['xmlnsc' : 0xfdc44f0]
(0x01000000:Folder):TestRoot = (
(0x03000000:PCDataField):a = '1' (CHARACTER)
)
) |
|
| Back to top |
|
|
| pavel112233 |
| Posted: Tue Oct 04, 2016 12:05 pm Post subject: |
|
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
| timber wrote: |
I take back my comment about your ESQL field reference...you're already doing what I recommended.
Surely the next step is a user trace. That should provide some useful insight into what's going on in your flow. I would not try anything else until I had done that. |
what do you mean by user trace? I thought I did that - trace node.. |
|
| Back to top |
|
|
| pavel112233 |
| Posted: Tue Oct 04, 2016 12:10 pm Post subject: |
|
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
Generally speaking I did nothing unusual, everything is by default, so why it still doesn't work "from the box"? It supposed to be very easy task to insert a row into table ((
Perhaps I'm doing something wrong at the very start? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 04, 2016 12:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pavel112233 wrote: |
| what do you mean by user trace? I thought I did that - trace node.. |
No. When @timber mentions user trace (as I did earlier), we both mean running the flow with the user debug trace switched on, so as to determine exactly what's happening. For example, it's possible that the code is correctly finding the "1" but the database is inserting a null for some reason.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 04, 2016 12:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The user trace can be run in conjunction with the Trace node; simple set the output of the Trace node to be "user trace" which IIRC is actually the default.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Oct 04, 2016 12:19 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| timber wrote: |
| Also, and before somebody like rekarm01 pops up and points it out...the value '1' is not CData. It is PCData (Parsed Character Data). CData is data that is wrapped in a <[[CDATA[ ]]> section. |
I'm having a bad day semantically.
| timber wrote: |
| [edit] and it's not mixed content either. 'Mixed content' is text data that occurs before, between or after the child tags in the content of an enclosing tag. |
A really, really bad day.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pavel112233 |
| Posted: Tue Oct 04, 2016 12:59 pm Post subject: |
|
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
| Vitor wrote: |
| pavel112233 wrote: |
| what do you mean by user trace? I thought I did that - trace node.. |
No. When @timber mentions user trace (as I did earlier), we both mean running the flow with the user debug trace switched on, so as to determine exactly what's happening. For example, it's possible that the code is correctly finding the "1" but the database is inserting a null for some reason. |
I did that:
mqsichangetrace TESTNODE_pavel -u -e default
mqsireadlog TESTNODE_pavel -u -e default -o trace.xml
but the content of trace.xml doesn't say much:
<?xml version="1.0" encoding="UTF-8" ?><UserTraceLog uuid="UserTraceLog" userTraceLevel="none" traceLevel="none" userTraceFilter="none" traceFilter="none" fileSize="104857600" bufferSize="0" fileMode="safe"/>
obviously I'm doing something wrong again.. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Tue Oct 04, 2016 7:24 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| timber wrote: |
| Also, and before somebody like rekarm01 pops up and points it out ... |
Please, no, nobody wants that. Anything but that ... I think I'll let someone else pop up and point out the difference between a tag and an element. 
| pavel112233 wrote: |
and when I try some properties of the message it works ok. the problem is in the BODY
| Code: |
INSERT INTO Database.test1 (ID, val) VALUES (InputRoot.Properties.Encoding, 2)
select * from test1
273 | 2 |
|
One thing to note here is that InputRoot.Properties.Encoding is an INTEGER, while InputRoot.XMLNSC.TestRoot.a (or the original InputRoot.XMLNSC.a / InputBody.a) is a CHARACTER. Perhaps a more explicit CAST would help.
| pavel112233 wrote: |
I did that:
| Code: |
mqsichangetrace TESTNODE_pavel -u -e default
mqsireadlog TESTNODE_pavel -u -e default -o trace.xml |
|
mqsichangetrace needs a few more arguments.
| pavel112233 wrote: |
but the content of trace.xml doesn't say much:
| Code: |
| <?xml version="1.0" encoding="UTF-8" ?><UserTraceLog uuid="UserTraceLog" userTraceLevel="none" traceLevel="none" userTraceFilter="none" traceFilter="none" fileSize="104857600" bufferSize="0" fileMode="safe"/> |
|
And very few users would want to wade through the raw output of mqsireadlog. Most would prefer to run it through mqsiformatlog. |
|
| Back to top |
|
|
| pavel112233 |
| Posted: Tue Oct 04, 2016 8:57 pm Post subject: |
|
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
"One thing to note here is that InputRoot.Properties.Encoding is an INTEGER, while InputRoot.XMLNSC.TestRoot.a (or the original InputRoot.XMLNSC.a / InputBody.a) is a CHARACTER. Perhaps a more explicit CAST would help.
"
Ok I'll try CAST but the thing is that both fields in database are character (varchar2 of oracle) |
|
| Back to top |
|
|
| pavel112233 |
| Posted: Wed Oct 05, 2016 12:22 am Post subject: |
|
|
Novice
Joined: 04 Oct 2016
Posts: 21
|
rekarm01,
success! great thanx! this cast works:
<TestRoot><a>1</a></TestRoot> ====>
cast(InputRoot.XMLNSC.TestRoot.a as integer)
- as a result I put "1" into the table.
but now I whant to have some string:
<TestRoot><a>test1</a></TestRoot> ====>
cast(InputRoot.XMLNSC.TestRoot.a as character)
- it doesn't work properly, as a result I literally have some chinese ieroglifs in the table 
整瑳 | 2
I undestand it has something to do with encoding so I try different code page values (273,1251,866..) :
cast(InputRoot.XMLNSC.TestRoot.a as character ENCODING 273)
they all don't work! I get ieroglifs all the time. |
|
| Back to top |
|
|
| timber |
| Posted: Wed Oct 05, 2016 1:01 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| Ok I'll try CAST but the thing is that both fields in database are character (varchar2 of oracle) |
You are making a very common mistake. Insteading trying different solutions all the time, you should collect diagnostic information, analyse that information and design a solution.
Have you done what rekarm01 suggested? If not, I *strongly* recommend that you change the code back (recreate the defect) and then take a user trace as follows:
| Code: |
mqsichangetrace TESTNODE_pavel -u -e default -l debug -r -c 50000
mqsireadlog TESTNODE_pavel -u -e default -o trace.xml
mqsiformatlog -i trace.xml |
When you read the trace you will almost certainly see all the information that you needed to diagnose this yourself.
Same goes for the current problem. Don't *try* different encodings - it's a dangerous game. You could end up using an encoding that's works for your unit test data and fails in production. Instead, you should find out what the correct encoding is and use that. |
|
| Back to top |
|
|
|
|
