This articles provides important information on new features and modifications which Stambia Designer S17 users need to know when upgrading to S18.
After reading this article, please feel free to ask questions on the forum or to the Support Team.
Upgrading the Designer? the Runtime? Analytics?
Stambia S18 new features are mainly focused on the Designer.
The Runtime is still with the version name "S17.2.x". This means that you can continue running your existing S17 Runtime for executing deliveries from S17 Designers as well as S18 Designers.
In the same way, Analytics does not need to be upgraded at all for receiving a S18 Designer's packages, or to view their sessions.
So, feel free to make use of the new Designer, especially for your new developments!
Upgrading a Workspace
Overview of the upgrade process
- Backup your workspace.
- Install the S18 software in a new folder
- Launch the new Designer on your workspace
- Select how to deal with your existing .tech project
- Launch a "Rebuild Cache" operation from the Impact view's menu
- Enjoy your new features!
Do I have to create a new workspace in S18?
No, when you will launch S18 on your existing workspace, Stambia Designer will start the upgrade process.
Stambia strongly recommends to backup your S17 workspace before proceeding.
And then you can open your workspace with Stambia Designer S18. Carry on reading to know more about the main changes.
What is the "Internal Resource Management" prompt about?
When opening a S17 workspace for the first time with Stambia Designer S18, you will be prompted with this question:
Internal Resources exist since the very beginning of Stambia. These resources define how the Designer can reverse a technology, transform Xpath expressions into SQL queries, convert datatypes, etc. Before S18, they were stored in the ".tech" project which is hidden by default.
Stambia Designer S18 introduces a new storage for Internal Resources, which will give you more control on them.
So for now, you have to make a decision about what to do with your legacy ".tech" project:
- Close: the .tech project will be kept in your workspace, but in the "closed" state. Choose this if you know that you made modifications in your .tech which you don't want to lose for future reference.
- Delete from workspace: the .tech project is removed from your workspace, but not from your hard drive.
- Delete permanently: the .tech project is removed from your hard drive (and from your workspace too). Choose this if you did not know that it existed or you know you never modified it.
- Keep: the .tech project will remain active. Choose this option if you actually mode modifications in your .tech which you really need to keep enabled.
Why are there warning icons on my Mappings?
The upgrade process leaves your existing mapping files unchanged: only the internal build files are regenerated. This warning icon informs you about the Mappings that are still under S17's architecture. However, if you execute them (directly or by executing any parent process) the generation will remain unchanged and continue to work exactly as in S17.
As soon as you will have edited and saved them, Stambia Designer will silently move them to the new architecture and this warning icon will disapear.
Note: the presence of non-migrated mappings in a S18 workspace, may produce errors when trying to Move Metadata nodes to Sub-metadata files. Thus, we recommend to migrate all the mappings that use this metadata before moving it.
Upgrade and version controlled Workspaces
Stambia generates internal files in the indy.build folder. In S17, this folder existed as a sibling of each Mapping in a Project. In S18 there is only a single indy.build folder under the root of each project.
If your versioning system required to ignore the indy.build folders, you now have to configure it to ignore the new indy.build folder located at the root of the project.
Concerning Designers who share objects through a versioning system: all the Designers that share the same objects should be migrated together. A S17 Designer cannot open mappings created or modified by a S18 Designer. We recommend to migrate at the same time all the Designers that work on the same projects.
Source in more than one Load is detected
In S17, when a source table was used in more than one Load Template, the mapping would silently compile - and sometimes produce undefined behaviour at execution.
Stambia S18 prevents any misbehaviour before compilation. The developer is now informed with a "Problem" icon on the join:
Cross Joins have to be designed
This paragraph only concerns mappings with RDBMS targets.
In version S17, when dragging source tables without designing a Join between them, a Cross Join was generated.
In version S18, those mappings will display with a "Problem" icon (red triangle) on the target:
This is normal: the new mapping model requires that Joins are designed so that the table is identified as part of this target's source.
These mappings should be modified in order to design the Join explicitly:
Mappings referencing Process parameters
If a Mapping contains expressions (Filters, Mapped fields, Joins, etc.) that reference the parent process parameters using a relative path syntax such as ${../../../../MY_PARAM}$ it may have to be updated in order to take into acount a new level introduced during code generation: ${../../../../../MY_PARAM}$
Note: Stambia discourages the use of relative path to reference parameters in Mappings and recommends using an absolute path such as ${~/MY_PARAM}$.
Processes referencing Template variables
If you have a process which references a template variable, for example:
${~/mapping/I_TARGET_TABLE - INTEGRATION/T - Insertion of rows in target/SQL_STAT_INSERT}$
... then you will have to modify it in order to take into acount a new level introduced during code generation.
Note: in this example, you may prefer to get the statistic using __ctx__.sumVariable("SQL_STAT_INSERT", "~/mapping")
Reinitializing mapping diagram
After migrating projects created in version S17 you might encounter a problem that will prevent you from collapsing the list of fields on a datastore in a mapping :
To solve this issue you should right click on the mapping name in the "Project Explorer" and go to Advanced>Reinit diagram.
This will reinitialize the diagram file that is used by the mapping. Please note that diagram files contain notes that you might have on your mapping. Before reinitializing diagram, you might want to copy the content of your notes and recreate them once the diagram is reinitialized.
If you do not use notes on your mappings you can simply remove all .map_diagram files from your migrated workspace. This way upon first opening of a mapping in S18/S19 its diagram file will be recreated from scratch.
Consulting sessions of deliveries built in S17
Stambia S18 brings a lot of changes when it comes to building a process based on your mappings. The structure of this process is so different that when you execute a delivery that contains a mapping built in S17 the new designer won't be able to correctly associate the steps of the old process to the new ones generated in a process in your workspace.
As a result, you won't be able to see the details of the actions executed as part of the delivery generated in S17:
You can still consult the details of those sessions in Stambia Analytics.
Alternatively you can rebuild your deliveries in S18/S19.