Skip to main content

Backwards Compatibility

This topic contains information about changes in the product that are important to consider when upgrading from iCore Integration Suite v2.84.

Script definitions​

Manual updates​

  • Script variable EventId: System defined variable EventId does not exist in v3. If used it should normally be replaced with the new variable JobId. The replacement has to be done manually.

Removed functions and objects​

FTP CommandMarked as obsolete in v2 and was only available in unmanaged script. Use FTP object instead.
Object Directory EntryThis object is removed in v3 and should be manually removed (if declared) in v2 before updating to v3. The Upgrade Readiness tool will issue a warning if it detects any Object Directory Entries.

Previously deprecated functions​

When iCPS v2.84 was released, it was possible to keep deprecated functions from previous iCPS versions in commented rows. Please note that in iCPS v3.xx this is not possible. Instead, when upgrading a Script from v2.84 to v3.xx the commented rows will show up as "obsolete function". These rows can safely be deleted.

For example:

'''// Obsolete function: Old Open Out File converted to Script object method.'''

Behavior changes in log output file​

The format of the log output file in the following functions is different from previous version:

  • WriteLogToFileByNode
  • WriteLogToFileByEvent

In the previous version each log entry was written to the output file according to the following format:

<Create date(yy-MM-dd HH:mm:ss)><space><space><Severity><space><space><Log message>

Example:

2012-12-12 12:31:12 3  A log entry

The new format is:

<Create date(yy-MM-dd HH:mm:ss)><space><space><Log level><space><space><Log message>

The log level is now text instead of a numeric value representing the log level.

Example:

2012-12-12 12:31:12 Information  A log entry

Note that the log level has been revised in v3.

Scrip object POP3​

Values supported in property State is:

  • MailState_Closed = 0
  • MailState_Connected = 2

iCPS v2.84 (unmanaged only) also supported:

  • MailState_Connection = 1
  • MailState_Closing = 2

HTTP client object certificate behavior changes​

Unmanaged

When no client certificate is explicitly set the HTTP client will look for certificates in the Current User\Personal certificate storage. If any certificate found then the first one is passed to the server.

Managed

In managed HTTP client no certificate is passed to the server unless it is explicitly set by the SetCertificate method of the HTTP client object.
This can cause communication failure between the client and server when switching to managed code in cases when the server requires client authentication and no certificate is set explicitly on the HTTP client object.
In version 3 there will be functionality to configure storage containing the client certification instead of configuring an explicit certificate.

Allocate Node Collection​

Since Node filters have been removed in v3 this function now lists Node entity filters instead of Node filters. Currently the only supported parameter types are the ones previously available in this function, i.e. Partner, Node Type, Node Type Version and text/numbers.

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.

Tracking identities and Large Integer variables​

The identity of tracking entities has been changed from a 32-bit integer value in v2 to a 64-bit integer value in v3. To allow working with these numbers, a new variable type (Large Integer) has been introduced. The use of this variable type is restricted and can only be used for passing to functions expecting the ID of a tracking entity, as well as Write String to Log, conditions and Set variable.

note

If Node IDs (or IDs of any tracking entity) is stored in an Integer List Object a manual update is needed to use the "Large Integer List Object" instead.
A large integer can be assigned to a normal integer variable, but a warning will be issued during compilation indicating a potential overflow situation. Existing scripts should be updated to use the new variable type when handling tracking entity IDs, although they will continue working "as is" as long as the IDs of tracking entities are below 2,147,483,647. 

Tracking​

Some differences apply to both tracking entity filters and to some of the tracking entities.

Event entity filters​

Due to the removal of some Event properties and changes in property enumeration values, not all v2 Event filters are compatible with v3 Event filters. References in filters to any of the properties listed below are removed during system upgrade:

  • Parent Event
  • Matched Event handler
  • Status
  • Thread ID (log entry)

It is recommended to go through customized filters and re-write them based on the new tracking entities (Job or Event depending on the filter contents). Note that the Update Readiness Check issues a warning if any incompatible filters exists.

Filter definitions on Trigger components​

In v2 every Trigger script instance defined an Event type for that instance. In v3 there are no Event type definitions created for a session Component configuration. Instead, a system startup Event (_SystemStarted) is created during start-up; this Event is used to execute Components that must be started at system start and run during the whole system session.

To achieve the same grouping or filter result in a v3 Component configuration filter as in a v2 Trigger component filter, use the new Lifetime property on Component configuration.

Log entries​

Regarding log entries, note the following when upgrading from v2 to v3:

  • It is no longer possible to track Component source on v2 Log entries for Components started from the Run Component tool.
  • The Thread ID property is not preserved.

Changed source name for iCore entries in Windows Event Log​

iCore Events written to the Windows Event Log are still written to the "Application" log but the Event source is changed from "iCore Server - [<system name>]" to "iCPS – [<system name>]". Any application filtering information from the Windows Event Log on iCore Event source name must be changed to the new name.

Import and Export​

note

When importing to a v3 system, the import file (.ieo) must come from a v2.84 system or later. For an older file, import it in a v2.84 system, run the Upgrade Readiness Tool, and export the file. 

Changes in Batch Import schema​

The Batch Import schema has changed, batch import response files must now be updated if they use ServerIdRequest (due to removal of resource components).

Partner and Settings​

In v3, it is not possible to:

  • Import a Partner attribute group that has the same CLR-name as one of its members.
  • Import a Setting attribute group that has the same CLR-name as one of its members.

Adapterflows​

Event listener entry​

  • Added property JobId.

Property "New event on each run"​

In v3, this property is implemented as a Tracking scope, which means an Event of type __iCore_TrackingScopeCreated and a Job with Component configuration __iCore_ChildJob is created on each run.

"Get iCore Event ID" activity​

  • New display name: [Get iCore Event and Job ID] activity.
  • Out property [Current Event ID Out] is now changed to [Job ID Out]
  • Out property [Parent Event ID Out] is now changed to [Event ID Out]

Adapterflows using the old activity might need to be manually updated if it has a binding to any of the above properties.

Code expressions​

Node.EventIdCode expressions referencing this Node property do no longer compile. The code snippet must be manually updated to use Node.JobId instead.

Behavior changes in Save Log to File activity​

The existing Save Log to File activity is now capable of also storing log entries related to a Job as an extension to the already supported Node and Event.
The output format of the file has changed (see Behavior changes in log output file).

The behavior for the different options is as follows:

Node​

Writes all log entries which are associated to the specified Node to file (same as v2).

Event​

Writes all log entries which are associated with the specified Event ID to file. In addition, all log entries which are created by Jobs that were created by the Event will also be written to file.

Job​

Writes all log entries which are associated to the specified Job ID to file. The log entries related to the Job are not included.

PowerShell and Cmdlets​

In the previous version, some Cmdlets referred to internal data types instead of public types. This has been changed.

  • Get-iCoreEntityType returns iCore.Public.Entities.EntityType instead of EntityTypeId.
  • Build-iCoreWebService uses iCore.Public.Entities.WebServiceCompilationOptions instead of WSCompilerSource as a source for parameter CompilationSource.
  • Get-ExportableiCoreEntity uses iCore.Public.Entities.EntityType instead of EntityTypeId as a source for Type param.

RunComp Tool​

When executing RunComp from the command line, note the following:

-DLLThis parameter is no longer available.
-SExecutes Script definitions only (in iCPS v2.84, the parameter executed Component configurations).
-CCExecutes a Component configuration.

iCore API​

Message format​

The message format of iCore API messages has been changed. Messages sent to and from iCore API are considered to be internal runtime messages and should only be read by functionality provided by iCore Solutions.

  • Adapterflow definitions: Parse iCore API init data / Send iCore API response activities.
  • Script definitions: Procedures defined in Script _iCPS_iCoreAPIBase distributed in "iCPS 2.80 - _iCPS_Utilities" package. There are also new functions available to support iCoreAPI interaction from Script definitions, Parse iCore API init data and Send iCore API response.
  • Workflow definitions: not supported at this time.

If you are using any of the supported iCore API functionality it will work without any changes. If using custom code to parse and create message data, changes must be done manually. For Script definitions the recommended way is to take a look at the Script definition _iCPS_iCoreAPIBase.

eCallType​

The value eCallType::AdapterflowExpressCall used in various methods of IEIcoreAPI2 is now deprecated. If used the effect is the same as using eCallType::ComponentExpressCall, which means the GUID must reference an existing component configuration and this component configuration is what will be executed when the express Event is processed by the service.

Changes in directory structure​

Server Cache Directory​

Previously called Script Comp Directory is renamed Server Cache Directory. New default location is %ProgramData%\\iCore Solutions\\iCPS\\Systems\\\<systemid\>\\ServerCache. This directory is automatically updated to this location when the service is first started after a system upgrade.

Script application directory​

The directory has been renamed "Compilation work directory" and is only used to store intermediate and temporary files during compilation of entities. It is no longer used during runtime. The directory is now located in %APPDATA%\\iCoreSolutions\\iCPS\\Systems\\\<systemid\>\\Compile.

During a system upgrade, the relevant content of the old directory is copied to the new location for the User that is running the installation.

Node directory​

The default directory for Nodes in v3 is %ProgramData%\\iCore Solutions\\iCPS\\Systems\\\<systemId\>\\Data\\Node. During a system upgrade, if and only if the old Node directory is located under the root iCore installation directory, the user is presented with a choice to move this folder during system upgrade.
If you choose to upgrade, make sure no definition directly accesses this directory without using functionality provided by iCore solutions (no hard coded).

Changes in information about attached systems​

In v2, this information was saved in the registry under HKLM\\iCoreSolutions\\iCore\\Systems. However, in v3 it has been moved to a file structure on disk located under %ProgramData%\\iCore Solutions\\iCPS\\LocalConfig during the installation of iCore.

Last updated on