| Author |
Message
|
| Adreno |
 Posted: Mon Jun 23, 2008 8:57 am Post subject: Problems with CWF and decimal values |
 |
|
Acolyte
Joined: 05 Jul 2007
Posts: 71
|
Hi,
I got an problem with the interpretation of decimal types in cwf. We got a message set with some fields declared as incoming xsd:decimal with a represetation of tns:decimal5f2, which means 5 positions over all and 2 positions after the point. Within my debug session a can see that the value is filled in correctly, but when the broker parses the message all positions after the point and the point itself are deleted. The message is incoming in XML.
As I read in another mwseries post there could be a problem with decimal types in CWF? Is there another work around than just changing types to string?
_________________
There are two kinds of people in this world: people who s***, and Chuck Norris... |
|
| Back to top |
|
 |
| vsr |
| Posted: Mon Jun 23, 2008 10:45 am Post subject: |
|
|
Centurion
Joined: 04 Apr 2006
Posts: 104
|
| Adreno wrote: |
| Within my debug session a can see that the value is filled in correctly, but when the broker parses the message all positions after the point and the point itself are deleted. The message is incoming in XML. |
That's exactly how CWF parser output a decimal field. The target application will parse this field using the same definition. It should understand virtual decimal points.
If you have to send decimal value as '100.99' instead of '10099' (5f2) you may need different approach. May be defining the field as string !? At the same time you need to make sure that the target application understands this. |
|
| Back to top |
|
|
| Adreno |
| Posted: Tue Jun 24, 2008 3:01 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 71
|
Hi,
is there any other solution than changing base typ to string? Out costumer seems to be very unsatisfied with that work around because it makes the needed typ validation unuseable?
_________________
There are two kinds of people in this world: people who s***, and Chuck Norris... |
|
| Back to top |
|
|
| fde |
| Posted: Thu Jul 30, 2009 12:30 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
I once again encountered this problem. While converting from mrm xml to mrm cwf, all decimal places gets erased.
I will change all occurences of decimal to string. I will raise a pmr too, because the implications on validation are too troublesome.
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 30, 2009 4:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Look.
IF CWF is changing the format of a decimal number, it is only doing so BECAUSE YOU TOLD IT TO.
Many many programs use "virtual" decimal points, where it is implied that the decimal exists before the nth digit of the integer value.
So it is entirely likely that, not only have you TOLD CWF to turn this decimal into an integer, but it is CORRECT to do so.
Please understand both your input message formats and your output message formats before wasting a lot of time with the wrong things. |
|
| Back to top |
|
|
| fde |
| Posted: Fri Jul 31, 2009 4:43 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
Ok, understanding where I told cwf to convert from decimal to int would be helpfull.
Since I want to support the full xsd:decimal possibilities, there must be a directive which describes how to convert decimal values like -12345,67 to a fixed with representation.
I would use virtual decimal points, if the processing system, would require those virtual decimal points.
Otherwise I would prefer a dynamic directive to produce cwf.
The problem is, I found no other directive besides the virtual decimal point.
Using "external decimal" there is no option to configure decimal point behavior besides the vitual decimal point. A default directive seem to convert the numbers after the decimal point. And the default directive seem to just delete everything after the decimal point.
If it is not the default directive deleting the decimal points and it is me who told cwf to do so, maybe you can describe where I can change the behavior.
A solution with several drawbacks is to switch the basetype to string.
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jul 31, 2009 6:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's not done a conversion to an integer.
It has output a decimal value in a physical format that does not contain an explicit decimal point character.
If you see a string of digits "12345", you have no mechanism for determining if this is an integer value or a decimal value.
You can assume that it is the value 12345.00. You can assume that it is the value 0.12345, or any other placement of the decimal point.
It all depends on what the Physical Format is DEFINED as, based on the previously determined design spec for the message, which is based on how the RECEIVER of the value is EXPECTING to get the data. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jul 31, 2009 7:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
It's not done a conversion to an integer.
It has output a decimal value in a physical format that does not contain an explicit decimal point character.
If you see a string of digits "12345", you have no mechanism for determining if this is an integer value or a decimal value.
You can assume that it is the value 12345.00. You can assume that it is the value 0.12345, or any other placement of the decimal point.
It all depends on what the Physical Format is DEFINED as, based on the previously determined design spec for the message, which is based on how the RECEIVER of the value is EXPECTING to get the data. |
If you need further proof (or possible examples) get a friendly COBOL guy to write out a series of COMP-3 fields with different picture clauses.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fde |
| Posted: Mon Aug 03, 2009 1:06 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
| mqjeff wrote: |
It has output a decimal value in a physical format that does not contain an explicit decimal point character.
|
I would like to configure an explicit decimal point character than, if there is no default decimal point character of universal validity. Can I do that?
The feature "virtual decimal point" would format my outputstring with a decimal character at a fixed position. In my understanding I would only use this, if the consuming application has the requirement for a decimal character at a fixed position.
I thought that there is a dynamic directive to parse in both directions.
Assuming a 9 digit decimal with 2 decimal places with padding char '0' and justification right:
xml -> cwf
12345.6 -> 00012345.6
12345.67 -> 0012345.67
Is this configurable for parsing in both directions?
Using virtual decimal point at 2:
12345.6 -> 0012345.60
12345.67 -> 0012345.67
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 03, 2009 4:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fde wrote: |
| mqjeff wrote: |
It has output a decimal value in a physical format that does not contain an explicit decimal point character.
|
I would like to configure an explicit decimal point character than |
Adjust the physical format on the CWF layer for the element.
After ensuring that the receiver of your message can handle having an explicit decimal point.
Likewise, to ensure padding, set the physical format with the correct justificaiton and padding. |
|
| Back to top |
|
|
| fde |
| Posted: Mon Aug 03, 2009 7:15 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
| mqjeff wrote: |
Look.
Please understand both your input message formats and your output message formats before wasting a lot of time with the wrong things. |
In my opinion, cwf was a flexible, very configurable format to produce string based message for most requirements on the message consuming side.
This seems to be wrong. As decribed in http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/topic/com.ibm.etools.mft.doc/ad16060_.htm all variations are optimized for cobol standards.
If the message consuming application is not cobol, most requirements cannot be implemented.
What physical format do you suggest to set up a fixed length based represenation?
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 03, 2009 7:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
CWF is specifically for Custom Wire Formats, generally optimized for Cobol and C message structures that are fixed width.
TDS is a flexible, configurable, physical domain to produce Tagged/Delimited STRING based messages for most requirements on the message consuming side.
I believe you want External Decimal. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Aug 03, 2009 7:35 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
|
| Back to top |
|
|
| fde |
| Posted: Tue Aug 04, 2009 12:46 am Post subject: |
|
|
Acolyte
Joined: 05 Jul 2007
Posts: 65
|
Thank you for constructive feedback. Since I need the described flexibility and because I have no cobol or c programs involving. TDS would be a better choice.
_________________
Global warming is an unintentional side effect of SOA's hotness.
-- http://soafacts.com/
a business integration methodology |
|
| Back to top |
|
|
|
|
