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 Index » WebSphere Message Broker (ACE) Support » Triggering Predefined Broker Node within User Defined Node

Post new topic  Reply to topic
 Triggering Predefined Broker Node within User Defined Node « View previous topic :: View next topic » 
Author Message
dan123
PostPosted: Tue Sep 23, 2014 1:38 am    Post subject: Triggering Predefined Broker Node within User Defined Node Reply with quote

Newbie

Joined: 18 Sep 2014
Posts: 6

Hi guys, first time poster so be gentle

I have a simple flow with a Reset Content Descriptor Node connected to a custom java user defined node.
The Reset Content Descriptor Node just changes the message domain and validates the content against the message set while the user defined node runs a set of rules on the parsed message.

I am wondering if it is possible to instantiate a predefined broker node (the RCD node) from the broker Java API. I have come across sample code like this...

Code:
CollectorNode colNode = new CollectorNode();
colNode.getInputTerminal("NEWIN");
mf1.connect(mqinNode.OUTPUT_TERMINAL_OUT, colNode.getInputTerminal("NEWIN"));


This seems to create a Collector Node, declare a terminal and connect the terminal. I assume this can be done for a RCD node as well.

My question really is can i pass the message content from a user defined node to a RCD node I create in code and take the processed message content back?

Is it even possible?
If it is possible I would arrive at a point where we have a self contained node without needing a simple subflow as well which would be ideal.

Any help would be really appreciated, thanks.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 23, 2014 5:17 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

First of all, you can convert a subflow into a "user defined node".

Second of all, you don't remotely need to use an RCD node to do what you are trying to do.

In ESQL you can use Create FIELD... DOMAIN().

In Java, you can create the right element of the last child of MbMessage.

Alternately, you can merely set the appropriate fields in the Properties tree to describe the data using the correct model/domain. It depends on what you really expect that an RCD node does.
Back to top
View user's profile Send private message
dan123
PostPosted: Tue Sep 23, 2014 5:34 am    Post subject: Reply with quote

Newbie

Joined: 18 Sep 2014
Posts: 6

for a little more context..

The message comes to the flow as standard BLOB.
I am using the RCD node to change the domain to MRM with validation on.
The message will then be routed into the user defined node for business rules processing.

I would like ideally to remove the RCD node and be able to change domain and validate in our custom Java Node before running rules.

I know it is possible to validate in ESQL with asBitStream but the Java API function toBitStream does not have the same functionality, mainly the ability to validate against the message set.

I could be way off here but I was hoping I could instantiate a RCD node in Java, turn settings on for validation, pass the message to it for processing and take the message back to continue with java business rules.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 23, 2014 5:42 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

Both ASBITSTREAM and toBitstream serialize data, they don't parse it.

If you want to parse a BLOB using an MRM message set, in Java, you can use createElementAsLastChildFromBitstream.

http://www-01.ibm.com/support/knowledgecenter/api/content/SSKM8N_8.0.0/com.ibm.etools.mft.plugin.doc/com/ibm/broker/plugin/MbElement.html
Back to top
View user's profile Send private message
dan123
PostPosted: Tue Sep 23, 2014 6:02 am    Post subject: Reply with quote

Newbie

Joined: 18 Sep 2014
Posts: 6

Sorry your correct with serialise.

Does createElementAsLastChildFromBitstream validate?
I believe this is just the opposite of toBitStream which does not validate.
According to the spec the last parameter 'options' is just a place holder for future enhancements.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 23, 2014 6:14 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

CreateElementAsLastChildFromBitstream won't *immediately* validate the data.

You can configure the JavaCompute node to Validate the message tree it creates, when you propagate out of it.

If you really wanted to "immediately" validate *inside* of a JavaCompute node, you could propagate to a known terminal, only connected to a passthrough and wrapped in a try/catch block. This would cause the message tree to be validated when it left the JavaCompute, and any failures would be caught. The passthrough would do nothing, and control would return to the line after the propagate.

But if all you want is a configurable RCD, then you can just set Validation on the JCN and do nothing inside the JCN other than createElementAsLastChildFromBitstream.
Back to top
View user's profile Send private message
dan123
PostPosted: Tue Sep 23, 2014 6:43 am    Post subject: Reply with quote

Newbie

Joined: 18 Sep 2014
Posts: 6

I want to immediately validate inside a user defined node.
It wont have the validation options you have mentioned.
Even if I could use the pass-through method you have outlined, this means adding additional nodes to the flow to process the message.
Seems counter intuitive when I am really looking to have it all contained in the user defined node.

looks to be beyond the realms of possibility without using another node, but I wanted to explore our options. Appreciate the responses.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Sep 23, 2014 6:52 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

I think you'll find that, as you access the message tree you've created with createElementAsLastChildFromBitstream to execute your rules, that the message tree gets validated.

If you want to validate the message tree completely, before you start to execute your rules, you can write code to walk the tree - breadth-first or depth-first. As you access each element, the bitstream will be parsed further and validated.

Again, try/catch around this will catch errors.

It's probably overkill to completely validate the message tree before you start to execute your rules.

And, again, you can write your user-defined node, put it in a subflow, and turn the subflow into a user-defined node.

Or just use a regular JCN instead of a UDN, and put that in a subflow which gets turned into a UDN.
Back to top
View user's profile Send private message
dan123
PostPosted: Tue Sep 23, 2014 7:17 am    Post subject: Reply with quote

Newbie

Joined: 18 Sep 2014
Posts: 6

Great suggestions Jeff i will investigate converting the entire subflow into a UDN.
I will end up with a russian doll type situation, with a UDN inside a UDN, just hope broker can handle this

If this doesn't work I can go the route of traversing the tree to force validation.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Triggering Predefined Broker Node within User Defined 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.