MQSeries.net :: View topic - XML, Output Queue and MessageSets.. guidance needed

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XML, Output Queue and MessageSets.. guidance needed

Goto page 1, 2, 3 Next

XML, Output Queue and MessageSets.. guidance needed

« View previous topic :: View next topic »

Author

Message

chirasukham

Posted: Mon Sep 09, 2013 12:33 pm Post subject: XML, Output Queue and MessageSets.. guidance needed

Novice

Joined: 07 May 2013
Posts: 19

Here is some code..

Code:

SET C = CARDINALITY ( XIn.PARTICP_DETAILS[] );

WHILE I <= C DO
   CREATE FIELD sOMP."Particp"[i]
   DECLARE mpsOMP REFERENCE TO sOMP."Partcip"[I];

   SET mpsOMP."PartCode" = CAST ( XIn.DBIN[I].PartCode AS CHARACTER );
   SET mpsOMP."SubPartCode" = CAST ( XIn.DBIn[I].SubPartCode ID AS CHARACTER );
   SET mpsOMP."EffDate"    = CAST ( XIn.DBIn[I].EffDate AS CHARACTER );
   SET mpsOMP."TermDate"    = CAST ( XIn.DBIn[I].TermDate AS CHARACTER ) ;

   SET I=I+1;

END WHILE;

This generates XML that looks like this after writing to the output queue.

Code:

I need it to look like

Code:

The message set portion for this part of the message looks like...

Code:

ParticpType
   Particp       MinOccurs = 0, Max Occurs = -1
   - {LocalComplexType}
      PartCode String12
      SubPartCode String12
      EffDate    String10
      TermDate String10

The MRM while I am generating this loop looks like.
(I'm unable to add screen dump here, so I've , manually typed it in here ).

- sOMP
- Particp
PartCode 39
SubPartCode NULL
EffDate 2013-09-09
TermDate 2104-05-28

This looks correct to me.

What am I doing wrong ?
I tried looking for ESQL to handle this type of loop, but there's so much documentation....
Could it be the MessageSet ?

Could some kind soul point me to a good reference source or guide me ?

Thanks so much.

Last edited by chirasukham on Tue Sep 10, 2013 2:23 am; edited 2 times in total

kimbert

Posted: Mon Sep 09, 2013 12:44 pm Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Before we help you, please can you help us by
- clicking on the 'Edit' button
- adding [c o d e] tags around the code and XML in your post.

thanks!
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too.

chirasukham

Posted: Mon Sep 09, 2013 1:47 pm Post subject: XML / Queue and Message set

Novice

Joined: 07 May 2013
Posts: 19

Here is some code..

Code:

This generates XML that looks like this after writing to the output queue.

Code:

I need it to look like

Code:

The message set portion for this part of the message looks like...

Code:

ParticpType
   Particp       MinOccurs = 0, Max Occurs = -1
   - {LocalComplexType}
      PartCode String12
      SubPartCode String12
      EffDate    String10
      TermDate String10

kimbert

Posted: Mon Sep 09, 2013 3:55 pm Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Quote:

Hope this is what is needed for code tags

Not really - your code and XML are still unreadable. The closing tag needs to be [/code].
You don't need to post the whole thing again - if you log in, you are able to edit your posts.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too.

chirasukham

Posted: Tue Sep 10, 2013 2:24 am Post subject:

Novice

Joined: 07 May 2013
Posts: 19

kimbert wrote:

Quote:

Hope this is what is needed for code tags

Not really - your code and XML are still unreadable. The closing tag needs to be [/code].
You don't need to post the whole thing again - if you log in, you are able to edit your posts.

I see what you're saying now... Is this better ?
Thanks.

kimbert

Posted: Tue Sep 10, 2013 3:09 am Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

Quote:

Is this better ?

Yes thanks - the fixed-width font preserves the indentation, which makes it much easier to see what's going on.

Some things to confirm:
- I am assuming that you are using the MRM domain with an XML physical format when writing this document?
- I am assuming that you are using v6.1 or later
- I am assuming that you have full control over your development environment, and you can therefore use command-line tools for tracing

Initial comments:
- You are using CARDINALITY with a counted loop to iterate over InputRoot. Some people on this forum will tell you that it's bad practice. I'll just say that there are better and easier ways to do it, assuming that you're on v7 or later.
- Your code and XML contain several typos. Just mentioning that before somebody else does.
- You seem to think that the debugger is the only way to diagnose errors in your message flow ( otherwise you would not have attempted to post a screenshot of the debugger ). I advise you to make use of Trace nodes and user trace - you don't have to stop using the debugger, but at least have the more powerful tools in your toolbox. If you don't know how to do use them, feel free to ask.
- In other to diagnose, I will need to see a debug-level user trace ( just the relevant portion ). Although, if you read it before posting you might end up diagnosing the problem before you post it

_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too.

chirasukham

Posted: Tue Sep 10, 2013 3:55 am Post subject: XML/ Message sets / Queues.

Novice

Joined: 07 May 2013
Posts: 19

Apologies for the typos. ( I have to hide the true code for fear of violating compliance issues, so I cant copy / paste... I hadto type it in ).

I will read up on trace nodes.
I don't have control over the broker side, so i would have get help from admins to get a debug level trace.
I am on WMB V 7.0.0.5.

Can't wait to get past rookie status ( sigh)..

kimbert

Posted: Tue Sep 10, 2013 4:26 am Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

OK - so user trace is problematic for you. That's quite a common problem. We can try to attack the problem from another angle first. I think the following facts are relevant:

- In an ideal world, the MRM domain should not be used for writing XML documents. XMLNSC is the recommended XML domain, since v6.1.
- The MRM domain needs the message tree under OutputRoot.MRM to have *exactly* the right structure. If the MRM parser cannot match the message tree against the message definition then it will output self-defining tags for all non-matched elements in the tree. However, you are getting atttributes when you want elements, so that is probably not your problem.
- The format of the output XML is controlled entirely by the model ( the message set ). If you are getting attributes instead of elements then it is because the message definition is telling the MRM parser to output attributes. Even if the actual XSD component is an element declaration.

At risk of repeating myself, it gets quite a lot simpler if you use the XMLNSC domain to write your XML document. And in case it is not obvious, it is OK to use MRM for parsing and XMLNSC for writing in the same message flow.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too.

Vitor

Posted: Tue Sep 10, 2013 4:37 am Post subject:

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

kimbert wrote:

OK - so user trace is problematic for you. That's quite a common problem.

What is this - bash an admin week?

Just because the admins don't give out command line access to the broker doesn't make it "problematic"; just means you have to ask.

And as I indicated here, it's not always done just to annoy developers.
_________________
Honesty is the best policy.
Insanity is the best defence.

chirasukham

Posted: Tue Sep 10, 2013 4:53 am Post subject:

Novice

Joined: 07 May 2013
Posts: 19

Quote:

And as I indicated here, it's not always done just to annoy developers.

And so, its done *SOMETIMES* just to annoy developers ?

In the meantime,
I've got some more work to do...
Let me do some more research, and digest all that's been posted here.
[/quote]

mqjeff

Posted: Tue Sep 10, 2013 4:58 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

It's generally best practice to prevent anyone who is not operational staff from having access of any kind to production environments.

It's frequently stringently required by industry or government regulation to do so.

The only person a developer hurts by failing to have a good relationship with the operational staff in charge of their production systems is themselves.

User trace should be a normal part of broker troubleshooting. Broker developers should be in the habit of requesting them, and broker admins should be in the habit of defensively providing them.

Vitor

Posted: Tue Sep 10, 2013 4:59 am Post subject:

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

chirasukham wrote:

Quote:

And as I indicated here, it's not always done just to annoy developers.

And so, its done *SOMETIMES* just to annoy developers ?

As I said earlier, it's usually more of a happy side effect. But not always.

_________________
Honesty is the best policy.
Insanity is the best defence.

Vitor

Posted: Tue Sep 10, 2013 5:05 am Post subject:

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

mqjeff wrote:

It's generally best practice to prevent anyone who is not operational staff from having access of any kind to production environments.

Or lower shared environments with stringent SLA / uptime requirements.

mqjeff wrote:

It's frequently stringently required by industry or government regulation to do so.

Or required by audit / security functions with various levels of paranoia / risk aversion.

mqjeff wrote:

The only person a developer hurts by failing to have a good relationship with the operational staff in charge of their production systems is themselves.

But IMHO there is no requirement for hugging. I know some of the local development teams read this forum.....

mqjeff wrote:

User trace should be a normal part of broker troubleshooting.

absolutely

There's also no question that some issues require user in non-development environments where developers do not have the needed access directly. The mantra of "well they should just recreate it in Dev" is hollow, pointless & unrealistic.

mqjeff wrote:

Broker developers should be in the habit of requesting them, and broker admins should be in the habit of defensively providing them.

Via a documented & repeatable procedure.
_________________
Honesty is the best policy.
Insanity is the best defence.

smdavies99

Posted: Tue Sep 10, 2013 5:22 am Post subject:

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

Vitor wrote:

Via a documented & repeatable procedure.

Otherwise known as standing behind them with a big hammer in one hand and a large piece of wet fish in the other.

Seriously, if the OP does not even have access to a dev machine without involving admins then I have to wonder what sort of site he's working on.
_________________
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.

chirasukham

Posted: Tue Sep 10, 2013 5:23 am Post subject:

Novice

Joined: 07 May 2013
Posts: 19

I know, and I agree.
I was just yanking a chain..

We are all concerned about security in the modern IT world, and we do everything necessary to protect our and our customer's intersts.

It's a culture to get used to, but when done and refined correctly, its a system that works well.

Display posts from previous:

Goto page 1, 2, 3 Next

Page 1 of 3

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XML, Output Queue and MessageSets.. guidance needed

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