I am testing a EGL generated wsdl with web services explorer and noticed that values in the file I'm fetching data from are null but are being returned as blank strings. I am using RBDv8.0.1.2. Although this servce works with my Web app, I would like the data values to remain null when being updated to the database from my RUI application. Is this behaviour normal or is there something I may be coding incorrectly to ensure that null values persist?

Hi,

Could you post the record you are using in the service and in the RUI application?
Does this happen in the preview pane, the deployed application, or both?
What application server are you using?
Service invocations from RUI use the EGL proxy. The proxy then creates an HTTP request to the service, so there are 2 places where the null could be lost. Since the value is null when you use the web service explorer it sounds like the blanks are introduced at the proxy or in the RUI app. Look at the data returned to the RUI app. In the service invocation returning to function output the current response (ServiceLib.getCurrentCallbackResponse().body), the data is in JSON format so it should be pretty easy to find the field in question. Is the field null in the body?

regards,
Joe

Hi Joe,

Thank you for your response.

I looked further into my issue and found that the Web Service was not the problem. I am losing my null values at the point of loading the data into my RUI widget's form which uses MVC. I have noticed that the formfield widget used by the form has an IsSqlNullable property, however, I cannot find any reference to this in the EGL help and therefore do not know its proper use and if it applies to my situation.

Any thoughts on why the value is being changed from null when used on the form in this fashion?
Thanks,
Rosanne

Hi Rosanne,

IsSqlNullable is not supported in RUI applications. You need to add a ? to the field type. In addition since there is an annotation on the field you need to set the initial value of the record to null.
myField string?{IsSqlNullable = true} = null;

regards,
Joe

Hi Joe,

Here is the record part we are using below as you can see we have defined the fields as being nullable:

record LintecOrderExtension {@XMLRootElement{namespace="http://data.???.???.???.com"}} OrderNumber decimal(6,0); OrderLineNumber decimal(3,0); LetterOfCredit string? {@XMLElement{nillable=true}}; FullWidth decimal(6,4)? {@XMLElement{nillable=true}}; DestinationCode string? {@XMLElement{nillable=true}}; Destination string? {@XMLElement{nillable=true}}; Consignee string? {@XMLElement{nillable=true}}; end

The reason I was asking about IsSqlNullable was because it came up on content assist.
Regards,
Rosanne

Hi Rosanne,

You are correct the ? will allow null values, but since there are {} the initial value won't be null. {} causes a field to be initialized to its initial value. For a string it's "" for a numeric it's 0. If you add an explicit initialization you can control the initial value. For any field you want to initialize to null add an = null. ie
LetterOfCredit string? {@XMLElement{nillable=true}} = null;
Does adding = null solve your problem?

regards,
Joe

Hi Joe,
I have a similar problem when using sqllib.unloadTable.
I have defined the field
dataitem NOMEUTENTI STRING {@XMLElement{nillable=true}}end
in dataDefinitions and
NOME NOMEUTENTI?{@XMLElement{nillable=true}};
in the record definition
But when I use unloadTable the field contains "\".
The result is disastrous when I have to transfer data.
Any other Idea?
paoloc

Hi Paoloc,

I'm not certain if the is a record used for the SQL if it is it should have isSQLNullable = true.
You should also add = null to the field definition.
NOME NOMEUTENTI?{@XMLElement{nillable=true}} = null;
in the record?

When we convert XML to a record we initialize the record, see my above post Jan 26, 2012 04:42:14 PM which describes how field are initialized.

regards,
Joe

Paolo,

I noticed you said you were having a issue when using the unloadTable functionality.

The way this works is that for a column with a "blank" value, EGL sets the value of "\ " in the file. For nulls, it will be nothing between the delimiters.

So, if I had a table with the following values

Col1 = ABC
col2 = blank
col3 = null
col4 = DEF

Then the resulting record in the output file after unloadTable would be:

ABC,\ ,,DEF

The reason for this behavior is the "loadTable" needs to be able to distinguish between a blank and null so it uses an escape character and blank which is "\ " to represent the columns with a "blank" value.

If you use the EGL loadTable function to fill the tables on the receiving system, it will understand this and remove the \ when it inserts the column values.

I had to revisit this issue the other day and made the change to the data part in my rui to initialize  my decimal field to "null"

and I got the results I desired.  

Not sure what happened before when I initially posed this question.....??

 

Thanks,

Rosanne

At the risk of posting to an old thread...

When the record part is created from a wsdl using EGL Services>Create EGL Service Inteface, shouldn't the act of initializing the field(s) as null in a record part be automatically performed by the wizard for those fields having @XMLElement{nillable=true}?

Might this be a possible RFE or are there compelling reasons not to assume a null default value with @XMLElement{nillable=true}?

-Daron

I agree.

We currently run an ant script each time we extract a client interface from a wsdl to work around this issue.

I have created an RFE for this issue: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=62160

Kind regards,

 

Bram

Hi Bram,

I added my vote for your RFE

Thank you,

Daron

Hi Bram,

I also added my vote to the RFE you created.

Regards,

Rosanne