In this article
You can find below the major changes and improvements of the Stambia DI Runtime 2020 (S20.3.x) version.
This article only highlights the most important changes.
If you need further information, please consult the full changelog and/or reference documentation.
Prerequisites
Migration from S17
Stambia DI Runtime 2020 (S20) major version changes some important part of the software which require your attention.
Migrating from Stambia DI Designer S17, S18 or S19 require to follow the migration guide, which can be found in the following article.
If you are simply updating from another Stambia DI Runtime 2020 (S20) version, simply follow the minor version upgrade guide, as usual.
What's new in Stambia DI Runtime 2021 (S20.3.1)?
Read Mail Action
When multiple received emails contained attachments with the same name, the attachments were overridden (only the last one was kept).
While reading emails, an attachment is extracted, if a file with the same name already exists, it will be prefixed or suffixed with a number instead of being replaced.
For example :
Mail 1 with attachment File.txt
Mail 2 with attachment File.txt
In the Mail Files Folder : the 2 attachments are created :
Complete changelog
The complete changelog with the list of improvements and fixed issues can be found at the following location.
What's new in Stambia DI Runtime 2020 (S20.3.0)?
Delivery Repositories improvements
Configuration and flexibility improvements
Delivery Repositories are the locations where the Runtime will look for the delivery files at execution.
They have been improved in this version to be more flexible and configurable.
The configuration in Runtime configuration file (engineParameters.xml) has changed and repositories are now working with plugins.
Example of the new Runtime Delivery Repository Configuration:
<repositories>
<deliveryRepository name="default" class="com.stambia.repository.delivery.FileDeliveryRepositoryPlugin" default="true">
<parameter name="folder" value="build/deliveries/"/>
</deliveryRepository>
<deliveryRepository name="webservices" class="com.stambia.repository.delivery.FileDeliveryRepositoryPlugin" default="true" webservice="true">
<parameter name="folder" value="build/deliveries/webservices/"/>
</deliveryRepository>
</repositories>
There are different Delivery Repositories plugins, allowing to store deliveries locally on the local file system, allowing to store the deliveries remotely on Analytics, and more...
Each Delivery Repository plugin has its own way to store and retrieve deliveries, depending on your requirements.
This new system will allow us to provide new way to store deliveries easily, by delivering new plugins when necessary.
Default plugins shipped within Runtime represent the usual repositories which were available on previous versions.
They have simply been transformed into plugins now: File Repository, HTTP Repository V1, and HTTP Repository V2.
Except this, they work the same way as in previous version.
This improvement only changes the way the Delivery Repositories are configured in Runtime, this does not change anything about existing deliveries or configurations.
You can refer to Runtime's reference documentation for further information about the new configuration of repositories.
Legacy repositories configurations are still supported.
If you have legacy repositories configuration from previous Runtimes you can use them in the Runtime, they will work.
However, we suggest using the new repository configuration presented above in this document when possible, it is now the recommended way to configure the repositories.
HTTP Repository V2 - Default delivery path
When using an HTTP Repository V2 to perform delivery pulling from Analytics 3.x.x, executing deliveries require to define the full Analytics path to the delivery, such as: <Analytics Project Name>/<Analytics Package Manager Name>/<Delivery name>
This means that you have to know the exact path of the delivery to execute on Analytics.
We added a new parameter named "defaultDeliveryPath" which allows to define a default delivery path to be used when executing a delivery from this repository.
Example:
Example of Analytics V3 Repository :
<...>
<repositories>
<deliveryRepository name="remoteV3" default="false" class="com.stambia.repository.delivery.HttpDeliveryRepositoryV2Plugin">
<parameter name="url" value="http://localhost:8080/analytics"/>
<parameter name="user" value="stambia"/>
<parameter name="uncryptedPassword" value="stambia"/>
<parameter name="unreachableTolerancePeriod" value="30000">
<parameter name="environment" value="myEnv"/>
<parameter name="defaultDeliverypath" value="MyProject/MyPackageManager"/>
</deliveryRepository>
</repositories>
<...>
This default path be added before the delivery name when executing a delivery from this repository without specifying the full delivery path.
The parameter is expecting a path with the following syntax: <Analytics Project Name>/<Analytics Package Manager Name>
When no default delivery path is defined, the user has to specify the full path of the delivery when executing, as usual.
For example, if you define the parameter to MyProject/MyPackageManager, if trying to execute a delivery named "MyDeliv", it will try to execute "MyProject/MyPackageManager/MyDeliv".
When the parameter is defined, you can execute deliveries with or without the full path.
If the full path is not specified, the default delivery path is added automatically being the scenes.
Example of executions with and without the full path:
Repositories usability improvements
To avoid misconfigurations, the Runtime will now refuse two start in the following situations, which are not supported:
- when defining two repositories with the webservice attribute set to true, because only one webservice repository is allowed at once in a Runtime.
- when defining multiple repositories with the default attribute set to true, because only two repositories can be defined as default at once, one for standard deliveries, one for webservice deliveries.
Repositories were not working when no configuration in Runtime
When no repository at all is defined in Runtime configuration file, the Runtime creates default repositories.
Those default automatically created repositories were not working properly.
Executed / published deliveries were not found and not accessible.
This has been fixed.
Runtime ciphering key
A new parameter called "deliveryPasswordCipheringKeyName" has been created to define a key which will be used only for delivery passwords.
This parameter will be applied only when encrypting / decrypting password for deliveries, and not be applied for the passwords of engineParameters.xml files, and any other places.
<parameter name="deliveryPasswordCipheringKeyName" value="key_functional_name">
The parameter "passwordCipheringKeyName" has been renamed to "globalPasswordCipheringKeyName" for clarity (previous naming is still supported for compatibility purposes)
<parameter name="globalPasswordCipheringKeyName" value="key_functional_name">
Have a look at Ciphering Key article for more details.
Scripting Context improvements
Credentials with "executeRemoteCommands"
The Scripting Context method "executeRemoteCommands" allows to execute multiple Runtime commands.
The current method allows to execute the commands on a remote Runtime but did not support defining a user and password, when the remote Runtime is secured.
We therefore added a new method signature which allows to define the user and the password of the remote Runtime.
The syntax is the following:
__ctx__executeRemoteCommands(String Host, String Port, String Commands, String Separator, String User, String Password)
Example:
Runtime commands improvements
Execute Delivery with repository
The "execute delivery" command supports a new parameter "repository" to define the Runtime Delivery Repository in which the delivery will be searched.
When this parameter is not defined, the delivery is searched in default repository as usual.
Example:
execute delivery MyDeliv repository MyRepo
Have a look at Administration guide for more details.
Purge session id
The "purge" command supports a new "sessionid" parameter to purge sessions through their id.
Example:
purge keep 0 session sessionid c0a83801017430757cea41e329eb8fe7
Have a look at Administration guide for more details.
WebServices Timeouts
Prerequisites:
- Component Base 2.0.5 or higher
or
Prerequisites:
- Component HTTP REST 2.0.3 or higher
Runtime now supports defining connection and read timeout when performing web services operations.
This is supported on WSDL Metadata and HTTP REST Metadata.
Refer to the components release notes for further information about this change:
Minor improvements and fixed issues
This version also contains some other minor improvements and fixed issues, which can be found in the complete changelog.
Complete changelog
The complete changelog with the list of improvements and fixed issues can be found at the following location.