| Author |
Message
|
| kwelch |
 Posted: Tue Jan 11, 2005 9:16 am Post subject: not getting expected output |
 |
|
Master
Joined: 16 May 2001
Posts: 255
|
Hi,
I am testing a messageflow and am not getting the expected resulte. My co-worker ran the messageflow through debugger and everything gets formatted correctly but when I look at the message on the output queue some of the attributes aren't there. Actually it seems to be some of the ones from the Input message. Anything I hard code appears. It would almost seem like it isn't recognizing my XML but I do get some elements out. I was wondering if there were any known problems when formatting attributes? We are at WBIMB v5 CSD 4.
Here is a code snipet of what I am doing:
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr)attr_index = '1';
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr)attr_name = 'claim_num';
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr)attr_value = "InputBody"."transmission_data"."ECM"."doc_attr"."claim_num";
claim_num is what does not appear.
Here is my input:
- <transmission_data>
-
- <Header>
<Vendor_Id>Vendor</Vendor_Id>
<Dcn>01234567890</Dcn>
<Transmission_File_Name>file.txt</Transmission_File_Name>
<Request_Type>metadata</Request_Type>
<Source_Id>src</Source_Id>
<Application_Id>eor</Application_Id>
<Workflow_Id>????</Workflow_Id>
<Transaction_Type>paymentrequest</Transaction_Type>
<Environment>DEV</Environment>
<Message_Type>request</Message_Type>
<Duplicate>N</Duplicate>
<Correlid>746573744a414e3730350000000000000000000000000000</Correlid>
</Header>
- <ECM>
-
- <ecm_application_name>
</ecm_application_name>
-
- <ecm_operation>
<Name />
<Mode />
</ecm_operation>
-
- <ecm_ret_code>
<Flag />
</ecm_ret_code>
-
- <dctm_object>
<default />
</dctm_object>
-
- <doc_attr>
<claim_num>ABC1234 C</claim_num>
<policy_num>555555555</policy_num>
<loss_date>3/16/2002 12:00:00 AM</loss_date>
<loss_state>29</loss_state>
<benefit_state />
<adjuster_id>00004JARVIS12898</adjuster_id>
<ssn>111-22-3333</ssn>
<provider_tin />
<claimant_last_name>McCarty</claimant_last_name>
<claimant_first_name>Annie</claimant_first_name>
<nurse_last_name />
<nurse_extension />
<insured_name>John Jones</insured_name>
<service_from_date>20020507</service_from_date>
<service_to_date>20020507</service_to_date>
<field_office>CFC</field_office>
<account_id>1234A</account_id>
<restricted_group />
<received_date>20040413040358</received_date>
<xml_creator>CREATOR</xml_creator>
<xml_modifier>Source</xml_modifier>
<ecm_scan_datetime>20040412</ecm_scan_datetime>
<ecm_doc_control_number>00286H165501</ecm_doc_control_number>
<packet_control_number />
<EOR_packet_control_number>86-H-16550-1</EOR_packet_control_number>
</doc_attr>
-
- <file_info>
<URI>default</URI>
<URL>default</URL>
<file_in_target>default</file_in_target>
</file_info>
-
- <doc_data>
<doc_data>default</doc_data>
</doc_data>
-
- <user_info>
<user_id>default</user_id>
</user_info>
</ECM>
</transmission_data>
Everything under transmission_data.Header comes out ok. When I get to the OutputRoot.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr).attr_value nothing comes out.
Sample output:
<ecm_cmd_doc>
<ecm_application_name>wceor</ecm_application_name>
<ecm_operation Mode="asynchronous" Name="create"/>
<dctm_object dctm_object_type="wcmedbill_doc" object_id=""/>
<doc_in>
<doc_object>
<doc_attr attr_index="1" attr_name="claim_num" />
<doc_attr attr_index="1" attr_name="policy_num"/>
<doc_attr attr_index="1" attr_name="loss_date" pattern="MMddyyyy"/>
<doc_attr attr_index="1" attr_name="loss_state"/>
<doc_attr attr_index="1" attr_name="benefit_state"/>
<doc_attr attr_index="1" attr_name="adjuster_id"/>
.....
<file_info file_in_target="false"/>
</doc_object>
</doc_in>
<user_info user_id="wcmb_usr"/>
</ecm_cmd_doc>
Any thoughts would be appreciated. I feel like it has to be something really simple. What bugs me though is everything looks good in debugger.
Thanks,
Karen |
|
| Back to top |
|
 |
| tillywern |
| Posted: Tue Jan 11, 2005 4:49 pm Post subject: Maybe a null somewhere |
|
|
Centurion
Joined: 28 Jan 2003
Posts: 109
Location: Colorado
|
Verify that any fields you are using are not null. An easy to do this is to use a coalesce statement and set the value to a string of NULL ENCOUNTERED if the string is null.
I don't know why the debugger would lie to you. However at least a COALESCE statement would tell you if the result is null and therefor not appearing in the output. |
|
| Back to top |
|
|
| JT |
| Posted: Tue Jan 11, 2005 6:41 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
Karen,
Try turning on a debug trace and reviewing the trace file to see what happens to that particular output element. It may very well be that the path to the input element 'couldn't be navigated', resulting in a null value being assigned to the output element. |
|
| Back to top |
|
|
| kwelch |
| Posted: Wed Jan 12, 2005 6:39 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Jt and Tillywern,
I have tried all those things. It navigates to the path ok. Then says it is doing a tree copy. It never says what the value it is moving in is though. The field is definitely not NULL as I see it on the input message and I tried moving the field as a straight field and not an attribute and that worked but then I lost the first two attributes. I think this has something to do with attributes but not sure what? Thanks!
Karen |
|
| Back to top |
|
|
| javaforvivek |
| Posted: Thu Jan 13, 2005 4:09 am Post subject: |
|
|
Master
Joined: 14 Jun 2002
Posts: 282
Location: Pune,India
|
Karen,
I tried your code, and it gave me the same output as yours.
But then I tweaked your code a little and got following:
Input:
<transmission_data>
<Header>
<Vendor_Id>Vendor</Vendor_Id>
</Header>
<ECM>
<doc_attr>
<claim_num>ABC1234 C</claim_num>
</doc_attr>
</ECM>
</transmission_data>
I have removed much of your data, but kept those lines which are of primary interest.
I wrote following code in a compute node:
| Code: |
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr)attr_index = '1';
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr)attr_name = 'claim_num';
DECLARE valueOfAttr CHARACTER;
SET valueOfAttr = InputBody.transmission_data.ECM.doc_attr.claim_num;
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr)attr_value = valueOfAttr; |
I got following output:
<ecm_cmd_doc>
<doc_in>
<doc_object>
<doc_attr attr_index="1" attr_name="claim_num" attr_value="ABC1234 C"/>
</doc_object>
</doc_in>
</ecm_cmd_doc>
Hope this is of some help for your to proceed...
_________________
Vivek
------------------------------------------------------
...when you have eliminated the impossible, whatever remains, however improbable, must be the truth. |
|
| Back to top |
|
|
| kwelch |
| Posted: Thu Jan 13, 2005 6:35 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Thank you! I also learned that the following works too.
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].(XML.attr)attr_value = FIELDVALUE("InputBody"."transmission_data"."ECM"."doc_attr"."claim_num");
Karen |
|
| Back to top |
|
|
| martinrydman |
| Posted: Thu Jan 13, 2005 7:07 am Post subject: |
|
|
Centurion
Joined: 30 Jan 2004
Posts: 139
Location: Gothenburg, Sweden
|
Could soeone explain why FIELDVALUE is required here? I looked in the doc, and it says FIELDVALUE is used when the element isn't a leaf element (e.g. it's a XML element with attributes)
But in this case, claim_num is definitley a leaf, or am I missing something?
It's also real hard to understand why javaforvivek's solution should work...
/Martin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 13, 2005 7:42 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm not exactly clear on the problem either.
It seems to be a difficulty resolving the path to the element value, or perhaps resolving the destination element.
It would be somewhat helpful to see a TraceNode trace of the message tree, to see what type the element and it's value are.
Both javaforvivek's code (using an intermediate placeholder) and the FIELDVALUE are forcing the assignment to assign the value of the input element. I suspect using the VALUE clause on the output element might fix this as well.
But I think the only people who can really explain what's going on are those that have the source code...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kwelch |
| Posted: Thu Jan 13, 2005 8:43 am Post subject: |
|
|
Master
Joined: 16 May 2001
Posts: 255
|
Here is the explanation given by IBM:
After analysing this scenario we have come to the conclusion that
the behaviour you are seeing is to be expected. When dealing
with fields in a message tree, then some ESQL calls will refer to
the exact value of a named field and some will refer to the field
and all its children. For example you have has written the following
ESQL :
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].
(XML.attr)attr_value = InputBody.transmission_data.ECM.doc_attr.
claim_num;
The target for this assignment is a message tree field and the
source is a message tree field. Furthermore the assignment is
between two message tree fields that both have the same parser
type. Therefore an exact field copy occurs from the source
'SourcePartnerCode' field to the 'code' field.
In an XML message tree, the fields are stored as Name parent fields
with value children. Therefore the parsed input message structure
is :
(0x1000000)claim_num = (
(0x2000000) = '12341234 C'
)
Since this is a like parser copy then this structure will be copied
to the target field exactly as it is :
(0x3000000)code = NULL
(
(0x2000000) = '12341234 C'
)
This creates the code field with the exact value of the Name field
SourcePartnerCode (which is implicitly NULL) and then the value
child is copied as a child of the code field. The code field is then
given the field type of an (XML.Attr) as requested by the ESQL.
When this message sub-tree is presented to the XML Writer, then
it determines that it is an XML attribute and therefore takes the
direct value of the field, which in this case is NULL.
This behaviour stems from the fact that the product allows the user
to build a message tree structure however they like and do not
enforce any rules. The message tree constructed may be compatible
or incompatible with the parser it will be presented to. The ideal
in this scenario would have been for the tree copy to have detected
that the left hand side of the expression had specified a field
type that does not process child fields. This would then force the
target field to present its field value instead of a tree copy of
the field and its children. However, this is seen more of an
enhancement than a defect fix, especially since functionality
exists in ESQL that can stop the tree copy from occuring.
The FIELDVALUE function was introduced for this very purpose to
allow the user to specify whether they want the value of a field
or whether they wanted a tree copy.
So for example, if you had written:
SET OutputRoot.XML.ecm_cmd_doc.doc_in.doc_object.doc_attr[1].
(XML.attr)attr_value = FIELDVALUE(InputBody.transmission_data.ECM.
doc_attr.claim_num);
Then this would request the exact field value from the source field
and populate the target field with this exact value.
When you copied the value to an intermediate scalar CHAR variable
then I suspect you would have gotten the output you required. When a
scalar variable is specified as the target field on a SET Statement,
then this cannot accept a subtree. Therefore the value of the
field is taken instead of a tree copy being performed. AS mentioned
earlier, some ESQL calls will request the value of a field, some
will deal with trhe subtree the field represents.
When copying fields to create XML.attr fields, then you should
use the FIELDVALUE function to specify that you want the field
value and not a subtree copy.
Karen |
|
| Back to top |
|
|
|
|
