This section lists the limitations and known issues of this release.
It also provides information about any fixes or workarounds that exist
for resolving these limitations and issues.
Runtime
- Currency symbol is not validated in CurrencyValidator.
- Currency symbol cannot be displayed when bColl is used as a data
module.
- Type initialize does not report accurate exception messages.
- There are multiple validations for an input value and the valid
sequence is weird. This is cause by DOJO mechanism.
- If a value for the height property of a table is not specified,
a user cannot edit the table in Internet Explorer 8.
- When defining data mappings, validation exceptions occur during
mapping. This is caused by the absence of a validation mechanism when
the context.setValuteAt() is called.
- AJAX invocation can be launched only by a form.
- A direct pagination table does not support the “go to a specific
page” function.
Tooling
- The XUI editor does not support Linux operating systems.
- A .transaction file cannot be imported from
a .xml file.
- A .xui file cannot be imported from a JSP
file.
- XUI and transaction template files cannot be saved in a plug-in
folder, which is not efficient for sharing.
- Classes with inheritance relationship -- This Web services tooling
could partly support the generation of classes and WebSphere® Multichannel
Bank Transformation Toolkit resources
if there is inheritance relationship in WS types definition. In the
latest version, the tooling works correctly if all the classes in
the inheritance structure are insatiable. The tooling has not been
designed to work for the classes which are abstract classes or interfaces.
- Multiple embedded collection type -- This Web services tooling
could partly support the generation of classes and WebSphere Multichannel
Bank Transformation Toolkit resources
if there is complex classes composition relationship in WS types definition.
But there is an exception if there are more than one collection in
the composition relationship. For example, if 'List A' contains 'Bean
B', and then 'Bean B' has a field whose type is 'List C', the formatter
will be generated into structure as '*.*'. And it is not supported
by both Web services runtime and tooling.
- Camel case names -- The names of Java resources such
as classes, package and fields will be converted into camel case style
after the stub class generation. It is the behavior from XJC tool
which is used by JAXB implementation. But in our Web services tooling,
there are some defects in the camel case conversion imported by wsimport
(JDK tool). The conversion result sometimes is different from JavaBean standard.
And this defect will cause a problem during the data mapping.
- Enumeration and annotation -- Some features such as enumeration
and annotation are not supported now in latest version. It means users
can not define enumeration and annotation in WSDL types.
- In the WebSphere Multichannel
Bank Transformation Toolkit Transaction
Editor- operation, create a new operation definition; there will be
a generated implClass. But when moving the operation class to another
package, there's a popup message box ask: Update reference to "operation.java",
check this option, but you will find there's no change in implclass
for operation definition in transaction editor.
- When refer an element which is from an imported definition file,
the detail sub fields of the referenced element can not be navigated
in editor.
Processor:
BeanCollection cannot be defined
as a child data element of KeyedCollection.
For example, in
the following code sample, a BeanCollection is defined as the child
element of a Keyed Collection:
Processor definition:
<context id="creditCardsCtx" type="process">
<refKColl refId="creditCardApplData"/>
</context>
Data definition:
<kColl id="creditCardApplData">
<bColl id="creditCardApplDataBean" bean="com.ibm.btt.beancoll.CreditCardApplBean" />
</kColl>
You must revise it as follows:
<context id="creditCardsCtx" type="process">
<refKColl refId="creditCardApplData"/>
</context>
Data definition:
<bColl id="creditCardApplData" bean="com.ibm.btt.beancoll.CreditCardApplBean" />
Channel
There is a default rule in WebSphere Multichannel
Bank Transformation Toolkit channels
to define the data formatter and response formatter.
If you
do not specify them in the request, WebSphere Multichannel
Bank Transformation Toolkit uses csRequestFormat and csReplyFormat configured
in operation as data format and response format.
The operation
configuration file is as follows:
<QueryStockOp.xml>
<operation id="QueryStockOp" context="stockCtx"
implClass="com.ibm.btt.poc.opstep.QueryStockOp">
<refFormat name="csRequestFormat" refId="stockFmt" />
<refFormat name="csReplyFormat" refId="stockFmt" />
</operation>
<fmtDef id="stockFmt">
<fXML dataName="stockCtxData">
<fString dataName="code" />
<fString dataName="price" />
</fXML>
</fmtDef>
</QueryStockOp.xml>
Trace
- WebSphere Multichannel
Bank Transformation Toolkit trace
must be initialized at first before the applications use it. Otherwise,
the default trace configuration is set and the trace configuration
in btt.xml will not take effect. If WebSphere Multichannel
Bank Transformation Toolkit is not
initialized, the default trace target is WAS by using BTTLogFactoryToWASImp as
the implementation class of BTTLogFactory.
- When trace to WAS, the performance will be impacted by the WAS
service log. This is a WAS limitation. For more information, refer
to this WAS technical note. To resolve this issue,
the WAS service log must be disabled.