Hi All,

I want to know when to use Unicode Char and Unicode String fields while creating a Document in comparision to normal Char and String fields.

As far as my understanding goes, WebMethod is based on Java platform and in Java all characters and Strings are Unicode based. Hence I don’t understand what is the need of these additional 2 fields - Unicode Char and Unicode String and in which situation one shoud use them instead of Char and String fields.

Any input would be highly appreciated.

Regards,
Sourav

webMethods the company has several products. You’re absolutely right that Integration Server is Java-based. The other primary component, Broker, is written in C (there may be some C++ in there somewhere). The Unicode data types are carry overs from Broker. Use Unicode when you want to pass Unicode data through the Broker.

If you have non-IS broker clients publishing or delivering documents that will be consumed by an IS trigger, you have to make sure that your data types match. If a non-IS broker client uses a unicode data type, but the IS document type uses only the default string value, an exception will occur and the trigger will not fire.

This can occur when the doc type is created outside of IS and not synched with the IS doctypes. Shouldn’t happen if you create the documents in IS and then ensure that the non-IS client is publishing that definition. We had two teams whose definitions were stomping on one another.

Mark

Hi Mark and Rob,

Thanks for the input. However, still it is not very clear to me the limitation/usage of these two types of datatypes.

Let me put my question with respect to a specific scenario here -

1. I’m using webMethods 6.0.1. and JDBC Adapter 6.0.3. The underlying JDK version is 1.3.1 (which supports till Unicode 3.0).
2. Now in release notes of WebMethod Installet 6.0.1 what I found is it is complient till Unicode 1.2.8 (WebMethod 6.1 complies till Unicode 3.0).
3. Also the same release notes says that ‘string’ and ‘char’ datatypes should be only used for Latin-1 (iso-8859-1) characters (for the backward compatibility purpose with older version of brokers) and in general instead unicode_char and unicode_string datatypes should be used.

Now with this information I’m having further queries like -
a) Though WebMethod is Java based, don’t the char and string datatypes support any characters beyond iso-8859-1 chars (which char and string datatype in Java do support) ?

b) Do the unicode_char and unicode_string datatype of WebMethod support only those characters of Unicode which are supported by the WebMethod supported Unicode (i.e. 2.1.8 in case of WebMethod 6.0.1) ? So in that case, though I’m running WebMethod 6.0.1 on JDK 1.3.1 (which supports Unicode 3.0) I eventually can support all characters till Unicode 2.1.8, (instead of all Unicode 3.0.0 characters).

It would be great help for me if I can get these two queries clarified.

Regards,
Sourav

a) Yes, Integration Server supports more than the ISO-8859-1 character set. It’s underlying support is provided by java.lang.String. It’s the Broker that is limited in its support of “string” and “char” data types–it is not Java based.

b) I don’t know if IS gets support for newer versions of Unicode based on the JVM it is running on (there may be some internal things that restrict it) but fundamentally, if you’re going to passing data through the Broker, it doesn’t matter. Broker 6.0.1, which is not Java based, says it supports 2.1.8. So even if IS supports Unicode 3.0 because of the JVM, it’s unlikely that a 6.0.1 Broker will properly handle Unicode 3.0 data.

Sourav wrote:
“…I’m running WebMethod 6.0.1…”

Just to maybe help clarify my comments, the term “webMethods 6.0.1” is ambiguous. There are many components that makeup the “webMethods Integration Platform” (now called “webMethods Fabric”). The term “webMethods” doesn’t refer specifically to any one component, though people tend to use “webMethods” and “Integration Server” interchangeably.

Integration Server is Java based. Broker is not. Each of these components supports different data types (e.g. IS doesn’t have a “char” data type). I think this may be where some of the confusion arises if one thinks of “webMethods” as a single thing.

Hi Rob,

Thanks for the explanation.

I got your point related to difference in support available in webMethods Broker and webMethods Integration Server. And there by the final support will depend on the Unicode version supported by the webMethods Broker 6.0.1 (as it supports Unicode 2.1.8).

Also, when I meant webMethods 6.0.1, I actually meant webMethods Intergration Server 6.0.1 only. And still not sure why it cannot get support for newer version of Unicode from the JVM on which it is running on.
However, I believe it is better to assume that the Unicode support would be limited to the version what is officially published by webMethods in the readme.txt.

Regards,
Sourav