| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Trimming DFDL message tree using ESQL |
« View previous topic :: View next topic » |
| Author |
Message
|
| ragu_learns_iib |
 Posted: Wed Aug 15, 2018 5:50 am Post subject: Trimming DFDL message tree using ESQL |
 |
|
Newbie
Joined: 15 Aug 2018
Posts: 3
|
Hi there!
I have recently started using IBM IIB v10. One of the things I'm trying to implement is invoking a CICS service and parsing the response. The CICS call and the parsing are working well on the outset. The CICS response is fixed length and has arrays also. I'm trying to accomplish two things before using the CICS response to build my final response
1. Collapse trailing spaces in string fields to just one space. This is not the same as trimming all trailing spaces - I want to retain exactly one space instead of the sequence of spaces.
2. Remove "empty" instances from arrays. I get a count of populated instances for each array in the CICS response. So I want to retain exactly those many instances and delete the rest.
As an example, consider the following DFDL tree structure based on the CICS response
| Code: |
RES_ROOT
STATUS_OBJ
STATUS_CD (long)
SEVERITY (string)
STATUS_DESC (string)
CUST_ID (long)
ACCT_NUMBER (string)
ADDR_OBJ_COUNT (short)
ADDR_OBJ (array: minOccurs=10, maxOccurs=10)
ADDR_LINE1 (string)
ADDR_LINE2 (string)
CITY (string)
STATE_CD (string)
ZIP (string)
|
In the above tree...
Fields like STATUS_OBJ.STATUS_DESC and ADDR_OBJ.ADDR_LINE2 can have only spaces as values. So I do not want to trim them completely. I want to collapse them into exactly 1 space. As a side effect, I know the remaining string fields will also get exactly 1 trailing space. I'm OK with that.
ADDR_OBJ will always occur 10 times. But the number of valid instances is given in ADDR_OBJ_COUNT.
I want to remove only those many instances and remove the rest.
I'm able to implement this in ESQL using my limited knowledge of the available functions, etc.
What I noticed is that the code would be a lot more efficient if I was able to
1. Determine the type of each field and apply the collapse space logic only to string fields
I am currently using FIELDTYPE function to determine if a field is a Name or a NameValue.
If Name, I'm trimming using recursive calls. If NameValue, I'm trimming even for numeric types
2. Determine array types directly instead of checking CARDINALITY of each field
Is there any way to do these?
Also, I would really appreciate any pointers on alternative approaches to my main objectives.
Thanks and have a wonderful day!
Ragu |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Aug 15, 2018 6:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Firstly, that's one of the best problem descriptions I've seen in here for a while. What you're trying to do, what you've tried, all nicely laid out. I tip my hat to you.
Secondly, I wonder if you'd be better off setting the array elements to nillable, with spaces identifying the nil values. You'd still get 10 elements in the message tree, but the empty ones would be nulled out. Easier than using the ADDR_OBJ_COUNT as an index (though @timber will probably be along in a minute to explain how to do that!).
Thirdly, I'm not clear why you want one space left in the other fields. You could more easily nill those out as well, and have one space as a default on the output DFDL model. Can you expand on the requirement here?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ragu_learns_iib |
| Posted: Wed Aug 15, 2018 6:57 am Post subject: |
|
|
Newbie
Joined: 15 Aug 2018
Posts: 3
|
Vitor, thanks for your response and encouraging words 
| Vitor wrote: |
| Secondly, I wonder if you'd be better off setting the array elements to nillable, with spaces identifying the nil values. You'd still get 10 elements in the message tree, but the empty ones would be nulled out. Easier than using the ADDR_OBJ_COUNT as an index (though @timber will probably be along in a minute to explain how to do that!). |
I'll try this shortly. But I wonder whether/how this will work when the array instances have nested (child) fields, like how ADDR_OBJ has.
Also, will this cause non-array fields to also be nulled out (e.g. STATUS_OBJ.STATUS_DESC)? If so, then it will contradict with the other requirement of collapsing spaces
| Vitor wrote: |
Thirdly, I'm not clear why you want one space left in the other fields. You could more easily nill those out as well, and have one space as a default on the output DFDL model. Can you expand on the requirement here? |
Not having a trailing space is ideal! I was accepting a trailing space because I wasn't aware of the option you mentioned. So thanks again for that!
The requirement is this.
If a field has at least one non-space character, remove all trailing spaces
Else, retain a single space as the value for the field.
This is because the backend stores a single space as the value for many fields which do not have valid values. Unfortunate, but true. So our services have to handle this translation  |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 15, 2018 7:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ragu_learns_iib wrote: |
But I wonder whether/how this will work when the array instances have nested (child) fields, like how ADDR_OBJ has.
Also, will this cause non-array fields to also be nulled out (e.g. STATUS_OBJ.STATUS_DESC)? If so, then it will contradict with the other requirement of collapsing spaces |
You'd need to apply the nillable condition to the children as well. Null fields have no spaces so you'd need to fix that in the output DFDL. Some experimentation may be required to achieve the combination you need, and I'd advise against twisting the DFDL into knots just to avoid ESQL, especially during your learning stage.
| Vitor wrote: |
Not having a trailing space is ideal! I was accepting a trailing space because I wasn't aware of the option you mentioned.
The requirement is this.
If a field has at least one non-space character, remove all trailing spaces
Else, retain a single space as the value for the field.
This is because the backend stores a single space as the value for many fields which do not have valid values. Unfortunate, but true. So our services have to handle this translation |
You can get the copybook DFDL to trim all the spaces and declare all fully space filled fields as null. Then use the outbound DFDL to insert a space for null fields.
Like I said, a little experiementation may be needed.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ragu_learns_iib |
| Posted: Wed Aug 15, 2018 7:29 am Post subject: |
|
|
Newbie
Joined: 15 Aug 2018
Posts: 3
|
| Vitor wrote: |
You'd need to apply the nillable condition to the children as well. Null fields have no spaces so you'd need to fix that in the output DFDL. Some experimentation may be required to achieve the combination you need, and I'd advise against twisting the DFDL into knots just to avoid ESQL, especially during your learning stage. |
I'll definitely try this out and see if I can strike a combination that works. Another thing I have to keep in mind is that the changes should not be too elaborate since we are trying to implement this in a number of services. So your advise on keeping the DFDL changes simple enough makes sense in more than one way
| Vitor wrote: |
You can get the copybook DFDL to trim all the spaces and declare all fully space filled fields as null. Then use the outbound DFDL to insert a space for null fields. |
I think the default options when creating the DFDL message model from COBOL copybook did the first part for me, sans the null part. The parser output did not have any spaces for fields which had only spaces in CICS response.
For the second part, pardon my noobie question here.
Can you please elaborate on what the outbound DFDL is and how I can access/edit it? Is it the response message in generated .XSD file?
Thanks!
Ragu |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Aug 15, 2018 7:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ragu_learns_iib wrote: |
| Can you please elaborate on what the outbound DFDL is and how I can access/edit it? Is it the response message in generated .XSD file? |
It's whatever you're using to serialize and format the outbound message once you've processed the mainframe return message. I assumed another DFDL but if it's XML then an XSD. I further assumed that you don't process this copybook and then just stop........
If you don't have anything describing the outbound message, then that's a good case for using ESQL.
_________________
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
|
|
|
|
