| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| IIB 10 Mapping Node - pivot / denormalize? |
« View previous topic :: View next topic » |
| Author |
Message
|
| daffy99 |
 Posted: Tue Feb 13, 2018 8:56 am Post subject: IIB 10 Mapping Node - pivot / denormalize? |
 |
|
Newbie
Joined: 13 Feb 2018
Posts: 2
|
Hello everybody,
I am struggling to use the IIB 10 Mapping Node to pivot / denormalize a list of tree elements.
My inbound set of elements is flat
* key1
* value1
* key2
* value2
* key3
* value3
where any key* or value* may be null, indicating no data present.
The output tree is expected to be a complex type, following the pattern
<mylistentry>
<key/>
<value/>
</mylistentry>
I have identified the Append transform (and read the current docs) as the go-to candidate. I fully understand the nice (simple) use case as given in the docs, but am unable to move forward in solving the following two distinct problems:
a) I am trying to denormalize a group of elements - (key*, value*); pushing both key and value into Append produces the wrong *arity, and I seem to be unable to use a Join transform to logically group (key, value) before they go into Append.
b) I am unable to construct a context-sensitive filter ("Condition") for the Append - in an ideal world I'd simply but "self::text() != 'mynullvalue'" in there, but I do not seem to have the right self, and current() appears to be forbidden. Is there anything within Condition which I can use to get hold of the _current_ node (out of key1, key2, key3)?
I'd really appreciate pointers on how to address these challenges within the Mapping node!
FWIW, outside of the mapping node, I *could" use pre-processing of input using ESQL (post-processing would not be a good idea because of the NULL values in there and correlation challenges). |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Feb 14, 2018 6:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Seems to me that using an ESQL procedure for that would be the fastest way to deal with the situation. If you already have one, I would not bother trying to solve this using a map. Maps are great, but not every transformation is solvable by a map.
On the other hand if your inbound structure is not XML, may be redefining your DFDL parsing structure might be a better bet... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| daffy99 |
| Posted: Sun Feb 25, 2018 7:59 am Post subject: |
|
|
Newbie
Joined: 13 Feb 2018
Posts: 2
|
| fjb_saper wrote: |
| Seems to me that using an ESQL procedure for that would be the fastest way to deal with the situation. |
I agree. The (intellectual, yet real) challenge was the map though 
| fjb_saper wrote: |
| On the other hand if your inbound structure is not XML, may be redefining your DFDL parsing structure might be a better bet... |
Even better - a colleague immediately recognized that the DFDL is already in a suitable shape, because of it being DFDL and thus being a rooted tree by nature!
I simply had not realized that
* key1
* value1
* key2
* value2
* key3
* value3
all share the same root (which in my case is not exactly the DFDL root, but that's irrelevant). So for a map simply understand that the problem to solve mutates into
* root
** key1
** value1
** key2
** value2
** key3
** value3
And, suddenly, the "root" element logically groups.
Net effect: Three separate primary connections (three groups) from root into an Append transform. This then exposes three Local Transforms, each of which can have the right Condition expression to produce output.
Life can get so easy once you step out of the box... |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
