| Author |
Message
|
| simonalexander2005 |
 Posted: Thu Jun 08, 2017 7:49 am Post subject: Route node parsing input as hex |
 |
|
Acolyte
Joined: 13 Jun 2016
Posts: 55
|
Hi,
I'm making a very simple flow:
| Code: |
| MQ Input -> Route -> Multiple outputs depending on result of Route |
The input is BLOB (this can change - I know the incoming message is a simple fixed-length string, e.g. "1234CL7890"), and the Route node simply needs to route depending on the characters in position 5 and 6 (e.g. "CL" in the example just given).
Because BLOB provides the information in hex format to the Route node, the filter patterns I'm using currently look like the following:
| Code: |
| substring($Body/BLOB,9,4)='434c' |
Is there any way I can use the more human-readable option of having 'CL' instead of '434c' in the filter? Is there another domain I could use? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Jun 08, 2017 4:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The DFDL domain comes to mind... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| simonalexander2005 |
| Posted: Fri Jun 09, 2017 12:08 am Post subject: |
|
|
Acolyte
Joined: 13 Jun 2016
Posts: 55
|
| fjb_saper wrote: |
| The DFDL domain comes to mind... |
Wouldn't that mean creating a DFDL schema definition, to parse the string?
This is going to be a high-volume flow that's used just to filter the incoming message off to different flows - so I want to make it as lightweight as possible. Ideally I wouldn't parse the message at all - but I only need the 5th and 6th Characters from the incoming message to make that routing decision. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jun 09, 2017 1:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You could code a compute node and use whatever character representation you want in a case statement with propagates.
Just remember not to propagate by default at the end of the compute node unless you want a default routing.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jun 09, 2017 4:14 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| simonalexander2005 wrote: |
| fjb_saper wrote: |
| The DFDL domain comes to mind... |
Wouldn't that mean creating a DFDL schema definition, to parse the string?
This is going to be a high-volume flow that's used just to filter the incoming message off to different flows - so I want to make it as lightweight as possible. Ideally I wouldn't parse the message at all - but I only need the 5th and 6th Characters from the incoming message to make that routing decision. |
So you make sure you use parse on demand and never parse further than the routing code...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| timber |
| Posted: Fri Jun 09, 2017 5:28 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Personally, if the main requirement is to be fast and lightweight I would stay with the BLOB solution. You can always add a comment on the message flow canvas to document what the 'substring($Body/BLOB,9,4)='434c' means. |
|
| Back to top |
|
|
|
|
