| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How to preppend attribute to a JSON payload in Compute node |
« View previous topic :: View next topic » |
| Author |
Message
|
| hugo.tavares |
 Posted: Fri Dec 14, 2018 9:34 am Post subject: How to preppend attribute to a JSON payload in Compute node |
 |
|
Newbie
Joined: 13 Nov 2018
Posts: 2
|
Hi guys,
First, let me tell you that I'm a newcomer both to this forum and to IBM technologies.
Secondly, my question:
I am building a REST API with IIB v10, and I'm receiving POST requests with JSON payloads.
They look like this:
| Code: |
{
"message": "hello world",
"timestamp": 1544808407
}
|
I used a Compute node, and at the moment I have the following:
| Code: |
CREATE COMPUTE MODULE helloWorld_Compute
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL PreppendGuid();
END;
CREATE PROCEDURE PreppendGuid() BEGIN
DECLARE guid CHARACTER UUIDASCHAR;
SET OutputRoot.Properties = InputRoot.Properties;
SET OutputRoot.JSON.Data.id = guid;
CREATE LASTCHILD OF OutputRoot.JSON.Data FROM OutputRoot.JSON.Data;
END;
END MODULE;
|
Yet this returns me something like:
| Code: |
{
"id": "c5b819f0-7511-4ce4-a1ce-d0f89d76d60b",
"Data" : {
"message": "hello world",
"timestamp": 1544808407
}
}
|
And I wanted it to output this:
| Code: |
{
"id": "c5b819f0-7511-4ce4-a1ce-d0f89d76d60b"
"message": "hello world",
"timestamp": 1544808407
}
|
Can someone help me on this?
IBM's documentation on ESQL (and in what regards to JSON) is, at most, wretched...[/code] |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Dec 14, 2018 11:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
One possible solution would be:
| Code: |
| CREATE FIRSTCHILD OF OutputRoot.JSON.Data NAME 'id' VALUE guid; |
Other solutions are of course possible, but I chose this one as you've clearly found the CREATE statement in the wretched IBM documentation. If you want the GUID to be the first child of the Data element, then tell the domain parser that.
You could also fix your code:
| Code: |
| SET OutputRoot.JSON.Data[] = SELECT * FROM InputRoot.JSON.Data[]; |
(Notice I'm using the InputRoot as the source) but a single CREATE will outperform the SET/SELECT pair on any tree of any size and is, in my view, clearer on what it's trying to achieve.
As I said, any number of solutions and someone may post an even better idea that suits you more.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| hugo.tavares |
| Posted: Mon Dec 17, 2018 3:32 am Post subject: |
|
|
Newbie
Joined: 13 Nov 2018
Posts: 2
|
@Vitor: thank you very much! It obviously worked fine.
I am not aware of the ESQL API and how to use it, because it's very hard for me to learn only from a command reference + graphs explaining how the command should be used, as IBM does throughout most of the documentation and, again, their examples are simply wretched. |
|
| Back to top |
|
|
| timber |
| Posted: Mon Dec 17, 2018 4:36 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Yes, ESQL is not particularly well-documented. The main things to remember are:
- Everything you do in ESQL is done to a message tree. You never write to the output bitstream message directly.
- A parser (domain) converts the input BLOB (bitstream) into a message tree
- A (possibly different) parser converts the output message tree into a BLOB (bitstream).
That first point is not unique to IIB, but it does tend to trip up a lot of novices. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 17, 2018 5:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hugo.tavares wrote: |
| I am not aware of the ESQL API and how to use it, because it's very hard for me to learn only from a command reference + graphs explaining how the command should be used, as IBM does throughout most of the documentation and, again, their examples are simply wretched. |
The supplied samples are considerably less wretched, and in fairness to IBM they've chosen to document all their products / APIs / languages in a consistent manner. How much value this brings I leave for discussion.
IIB is not intended to be a self-learned product and your commendable efforts should be teamed with some formal training and/or mentoring from more experienced people on your site.
I especially commend to you the comments of my worthy associate; you'll see any number of posts in here from people who have got themselves tangled up believing they're working on a bit stream. I suspect this might have been the stone in your shoe; believing that you had to concatenate your GUID with the data rather than inserting the GUID at the correct place in the message tree.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
