Migration Issues and Usage Considerations

In this section:

This section describes migration issues and provides usage considerations when migrating from an iSM 5.x release to 6.0 and 6.01.


Top of page

x
XPATH Considerations

Previous releases of iWay Service Manager (iSM) supported an XPATH() function that implemented a subset of the formal XPath specification, which was modified to be more compatible with iWay requirements. Generally this conformed to section 2.5 - Abbreviated Syntax, of the following RFC:

http://www.w3.org/TR/1999/REC-xpath-19991116

As of iSM version 6.0.1, the XPATH() function implements the complete Xpath according to the RFC. Strict adherence to the Xpath specification may introduce some incompatibilities in function use. This is especially true in XPATH() expressions that included namespaces. To help avoid the need to make changes in existing application logic, the new function _IWXPATH() is introduced that implements the original iWay XPATH() implementation.

Note: The _IWXPATH() function is available in iSM version 5.6, where it is identical to the XPATH() implementation.


Top of page

x
iWay Functional Language

The iWay Functional Language (iFL) offers new functions that were requested by users to simplify the configuration of iSM. Some users, however, have written custom functions. Custom functions are not compatible with iSM 6.0, and must be slightly modified according to the following guidelines:

  1. The function must extend FunctionNode instead of funcNodeFunction.
  2. In order to allow user functions to be placed into packages other than com.ibi.funcs, the following methods must now be made public:
    • getMinPArms()
    • getMaxParms()
    • getDesc()
    • optimize()
    • getXValue()

These changes were made to facilitate the goal of developing a more secure server by enabling the runtime .jar files to be signed in a later release.

For more information on how to program a user function, see the iWay Programmer's Guide.


Top of page

x
XML Whitespaces

In earlier releases, XML parsing assumed that element data was information that was input to an analysis. In iSM version 6.0, the parsers follow strict compliance to the XML 1.0 specification.

If you decide to preserve whitespaces, you must choose the services (agents) carefully to make sure that they are mixed content aware. Most iSM services are mixed content aware.

Because requirements will differ between applications, each channel now offers an option to control XML whitespaces.

The property is now called Whitespace Normalization and it offers two options: trim or preserve.

Trim is used to remove leading and trailing whitespace characters. This was the default behavior In earlier releases. Preserve disables all whitespace normalization. Every character is returned as it appeared in the original document. This is compatible with XML 1.0 and XML Schema whitespace facet=preserve.


iWay Software