Backwards Compatibility
This topic contains information about changes in the product that are important to consider when upgrading from iCore Integration Suite v3.xx.
Script definitions
Removed functions and objects
The Upgrade Readiness Tool will issue an error if your system contains Scripts that use any obsolete functions or objects.
You will also receive warnings when attempting to upgrade a system containing such Scripts, or compiling a Script with obsolete functions or objects.
Define e-Mail variable, Init e-mail, Send e-Mail, Receive e-Mail
All Scripts using these functions must be rewritten using Mail objects.
Define HTTP Server, HTTP Command
All Scripts using these functions must be rewritten using HTTP client objects.
5250 Screen Scraping Object
This object is obsolete.
Scripts of type Standard (old)
A System upgrade will not be possible if any Standard (old) Script contains functions for defining or using old structure. If any such Scripts exist, they must first be rewritten with the Standard Script structure. Note that it is still possible to import Standard (old) Scripts with structures but these Scripts will fail to open and compile.
Standard (old) Scripts not yet updated will show as Standard (old) in iCore Administrator and in the Developer open dialog.
NT Event Log Object, NT Event Log Record Object
These objects are obsolete.
Cryptography Script objects
These objects are obsolete.
Mail message Script objects
The Encrypt and Decrypt methods are obsolete.
Infile Object
Buffers are handled differently in managed and unmanaged implementation. For more information, see respective property on the Infile Object. If you have used non-default values for buffer sizes it may be a good idea to review these values.
Behavior changes in Script function Parse infile (ver. 2)
In iCIS v3.30 (and earlier), this function does not return an error if it has finished parsing the structure but the infile still contains more data. The behavior occurs under the following conditions:
- The last item in the structure is a group at root level.
- The last group has been matched max number of repetitions.
-OR-
- There is a group (A) at root level which is followed by one or more groups that are conditional.
- Group A is matched max number of repetitions and the conditional groups that follow are not matched at all.
If you have updated iCIS (beyond v3.30) and want to retain the "old" behavior, please contact iCore support.
XML Parser Object
Whitespace is handled slightly different when parsing an XML Document Object that has been loaded from a file or a string that contains CDATA. For example, consider that the following data is loaded by an XML Document Object:
<Root>
<Element1 ><![CDATA[test1]]></Element1>
<Element2>
<![CDATA[test2]]>
</Element2>
<Element3>
<![CDATA[
test3
]]>
</Element>
</Root>
When parsing the XML Document Object, the CharactersData property will contain the following when the OnCharacters callback is invoked on the elements (square brackets are added for better visualization of new lines in the characters data):
| Element | Characters data (Native) | Characters data (Managed) |
|---|---|---|
| Element1 | test1 | test1 |
| Element2 | test2 | [CRLF]test2[CRLF] |
| Element3 | [CRLF]test3[CRLF] | [CRLF][CRLF]test3[CRLF][CRLF] |
XML Writer Object and XML Document
There can be differences in how XML data is represented when using the XML Writer Object or XML Document Object. In some cases, empty elements
which were previously stored as <element\></element>, are now stored in the more compact form <element />. There can also be
differences regarding insignificant whitespace: for example, an element previously stored as <element/> is now stored as <element/>.
The value of the XML is the same but problems may occur if you, for example, run tests that do exact string comparisons between the result of some operation and an expected value.
The XML Writer Object is now more restrictive which makes it easier to create valid XML. For example, the object no longer lets you assign the same name to multiple attributes within the same element.
WSMQ Queue Object
In iCIS v4.00, the WSMQ Queue Object only exists in managed implementation. If you have previously used the object in unmanaged implementation, note the following differences:
Open
- It is no longer allowed to perform receive when send access is defined in the Open method.
- A queue that is open with a defined channel that does not exist will not fail if the queue manager is set up with Channel Auto Definition.
- The transport type defined in the ChannelDefinition parameter will be ignored. All communication will instead use TCP as transport type, for example if the ChannelDefinition is "SYSTEM.DEF.SVRCONN/SPX/hostname(1414)", SPX will be replaced with TCP as transport type.
get_ReasonCode and get_CompletionCode
- get_ReasonCode and get_CompletionCode will not fail if the queue is not opened. Hence, failure codes can be received in Open or Close operations.
iCore WSMQ Trigger Monitor (EWSMQTrgMon.exe)
In the new implementation, the transport type defined in the command line argument for ChannelDefinition is ignored. All communication will instead use TCP as transport type, i.e. if the ChannelDefinition is "SYSTEM.DEF.SVRCONN/SPX/hostname(1414)", SPX will be ignored and TCP will be used as transport type.
Nodes
Node type version
Internet media type (property)
When upgrading from a previous iCPS version in which this property is not available, Internet media type will be set according to the existing Node type "file class" (provided that the file class is associated with a media type available on the computer from which the upgrade is done). For more information, see Node type
Web service definitions
The name of this entity has been changed to Web service client.
The type iCore.Public.Entities.IWebServiceDefinition has been renamed to iCore.Public.Entities.IWebServiceClient. This is a breaking change which may require that you manually update Workflows or Adapterflows that use this type in code expressions.
Workflows
The enum type iCore.Management.Service.ServerPartType has been moved and is now located in iCore.Public.Types.ServerPartType in the iCore.Public.Types assembly. Any Workflow that uses this type in, for example, variables or arguments must be manually updated.
If you have upgraded to iCIS v3.30.1 (Service Pack 1), note the following:
- iCIS v3.30.1 contains some new Workflow activities. Workflows that contain the new activities will not compile on systems running earlier versions of iCIS.
Web Administrator
In iCIS v4.0 Update 3, the feature to manually add or remove entity references ("user references") has been added. However, exporting entities with these references to iCore systems running earlier versions of iCore is handled differently depending on the version of the target system:
Exporting entities with user references to iCore systems running iCIS v4 Update 2 SP 2 (or earlier) – the user reference can be imported to the system even though no support for user references exist in these versions. Once imported, you can run the Test-iCoreEntityReferences cmdlet and delete the references detected as 'invalid'. If the invalid references are not removed manually, they will be removed automatically when the system is upgraded to iCIS v4 Update 3 (or later).
Exporting entities with user references to iCore systems running iCIS v4 Update 2 SP3 (or later) – the user references are ignored by the ImportExport tool and no user references will be imported to the target iCore system.
iCore Public API
In iCIS v4.0 Update 3, some new properties and methods have been added which means that Components that use the features listed below cannot be exported to iCore systems running earlier versions of iCIS v4. This limitation concerns the following features:
- The GetAll method for entity repositories for configurations and definitions.
- Workflows in which the value of the 'Errors' property of iCore.Public.AS2.IAS2Message are set.
- Workflows that contain the 'LoadErrors' property (or iCore.Public.Types.DiagnosticInfo) of iCore.Public.AS2.IAS2MDN.