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 IndexWebSphere Message Broker SupportTrimming DFDL message tree using ESQL

Post new topicReply to topic
Trimming DFDL message tree using ESQL View previous topic :: View next topic
Author Message
ragu_learns_iib
PostPosted: Wed Aug 15, 2018 5:50 am Post subject: Trimming DFDL message tree using ESQL Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Aug 15, 2018 6:23 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25318
Location: Ohio, 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
View user's profile Send private message
ragu_learns_iib
PostPosted: Wed Aug 15, 2018 6:57 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Aug 15, 2018 7:06 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25318
Location: Ohio, 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
View user's profile Send private message
ragu_learns_iib
PostPosted: Wed Aug 15, 2018 7:29 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Aug 15, 2018 7:54 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25318
Location: Ohio, 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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexWebSphere Message Broker SupportTrimming DFDL message tree using ESQL
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.