Welcome to Stambia Analytics!

This guide contains information about how to use the product to manage production tasks.


This document is intended for users interested in using Stambia Analytics to parameterize Packages and go into production, schedule executions, follow up the session’s executions, view sessions' details, ... .

Document Conventions

This guide uses the following formatting conventions:

Convention Meaning
boldface Boldface type indicates a graphical user interface associated with an action, or a product specific term or concept.
italic Italic type indicates a special emphasis or placeholder variable that you need to provide.
monospace Monospace type indicates code example, text or commands that you have to enter.

Other Stambia Resources

In addition to the product manuals, Stambia provides other resources available on its company website: and community website

Obtaining Help

To get help you can:

  1. contact our global Technical Support Center:
  2. consult the articles on our community website
  3. consult or post topics on our forum on


We welcome your comments and suggestions on the quality and usefulness of this documentation.
If you find any error or have any suggestion for improvement, please contact us at and indicate the title of the documentation along with the chapter, section, and page number, if available. Please let us know if you want a reply.

Installation of Stambia Analytics


Stambia Analytics needs the following requirements:

Stambia Analytics can run on any operating systems that meet these requirements.


Stambia Analytics consists of a .war file (or .ear file) that shall be deployed on the application server.

Before proceeding:

  1. Ensure that the application server uses java virtual machine 1.7 or higher.
  2. Define a STAMBIA_WEBAPP_HOME environment variable. This will be the folder in which Stambia Analytics will store parameters and repositories information.

Warning: for the STAMBIA_WEBAPP_HOME variable, prefer a folder outside the application server. Don’t forget to set up backup procedure on this folder.

Tip: in the name of the STAMBIA_WEBAPP_HOME variable, you can add the IP Port like STAMBIA_WEBAPP_HOME_8081 to specify another installation of Stambia Analytics. This is useful when there are two installations of Stambia Analytics on the same server.

Right management

The Stambia Analytics authentication relies on the application server authentication.
You have to declare the users and their roles on the application server.

Each user can have several roles in the following list:

The rights management in Stambia Analytics will rely on these roles.

Tomcat detail


To setup Stambia Analytics on tomcat:

  1. Declare the STAMBIA_WEBAPP_HOME environment variable in the the profile of the user who will launch tomcat.
  2. Add the users and roles in Tomcat
  3. start tomcat
  4. copy the .war file provided by Stambia in the Tomcat folder "webapps". Tomcat will auto-deploy the application.

Warning: Tomcat versions higher than tomcat 8 are not supported.

Managing users and roles in Tomcat

In order to add your users and roles, you have to modify the "tomcat-users.xml" file.

Adding a user can be done with the following block:

<user name="youruser" password="yourpassword" roles="admin-gui, manager-gui, analyticsAdmin, analyticsConnect" />

In this example, the user has the two Stambia Analytics roles "analyticsAdmin" and "analyticsConnect", but also the two Tomcat roles «admin-gui» and «manager-gui».

JBoss detail

JBoss 7


To setup Stambia Analytics on JBoss 7:

  1. Declare the STAMBIA_WEBAPP_HOME environment variable in the profile of the user who will launch JBoss.
  2. Add the users and roles in JBoss (see below)
  3. start JBoss
  4. copy the .war file provided by Stambia in the deployments JBoss folder. JBoss will auto-deploy the application.
Managing users and roles in JBoss 7
<security-domain name="analyticsRealm">
           <login-module code="UsersRoles" flag="required">
              <module-option name="usersProperties" value="${jboss.server.config.dir}/"/>
              <module-option name="rolesProperties" value="${jboss.server.config.dir}/"/>

JBoss 6


To setup Stambia Analytics on JBoss 6:

  1. Declare the STAMBIA_WEBAPP_HOME environment variable in the profile of the user who will launch JBoss.
  2. Add the users and roles in JBoss (see below)
  3. start JBoss
  4. copy the .war file provided by Stambia in the deployments JBoss folder. JBoss will auto-deploy the application.
Managing users and roles in JBoss 6
<application-policy name="analyticsRealm">
		  <login-module code=""flag="required">
             <module-option name="usersProperties">props/</module-option>
				 <module-option name="rolesProperties">props/</module-option>
				 <module-option name="unauthenticatedIdentity">anonymous</module-option>

Overview of the Stambia Analytics graphical interface

Here is an overview of Stambia Analytics graphical interface:

Setting Stambia Analytics

The Parameters of Stambia Analytics can be set up in the Windows->Parameters menu.
This menu will open the Parameters window in which Runtimes, Log Databases and Profiles can be defined.

Defining Runtimes

In the Runtime tab you can define connections to one or more Runtimes.

  1. Click on the Add button
  2. Specify a Name, the Host and the Port on which to connect
  3. Optionally set a User and Password if the Runtime is secured
  4. Test the connection through the Test button

If you check the Show in logs selection box, the Runtime name will appear in the selection combo box under the main menu.

If you check the Hide in navigator box, the Runtime will not appear in the selection Navigator view.

If you check the Disable log database proxy box, Stambia Analytics will not retrieve the session information from the Runtime.

When all the Configurations are done and saved, don’t forget to select the Runtime in the combo box under the main menu if you want to use it.

Note: To access to a Runtime, don’t forget to open the needed IP ports. By default 42000.

# If you configure Stambia Analytics to connect to the log databases using Datasources you should check the Disable log database proxy box on each Runtime.
# If your Runtime is configured to use a different log database than the default one: Add the corresponding JDBC drivers in:

Defining log databases

In the Log databases tab you can define connections to one or more logging databases.

  1. Click on the Add button
  2. Specify the Name
  3. Define the Connection:
    1. Select Standard if you want Stambia Analytics to open its own JDBC Connection to the database and provide:
      1. the JDBC Driver class
      2. the connection URL
      3. the User
      4. the Password
    2. Select Datasource if you want Stambia Analytics to use a Datasource defined in your Application Server and provide the Datasource Name
  4. Specify the schema name, and if needed, the tables prefix
  5. Test the connection through the Test button

If you select the check box Show in logs selection, the database name will appear in the selection combo box under the main menu.

Note: To access to a database, don’t forget to open the needed IP ports.

Tip: You can automatically fill the database information by connecting to a Runtime that knows the connection information. To do this, click on the Autoinit button and specify a Runtime host or IP, and a Runtime port.

Important: Don’t forget to add the JDBC drivers corresponding to the log databases in:

Defining Profiles

Profiles are useful to gather Sessions from Runtimes and log databases.

For example, a «Production» profile can be created to administer all Runtimes and logging databases dealing with production executions.

You can define a Profile in the Profiles tab.

  1. Click on the Add button
  2. Give a name
  3. Click on the button in the right of the Log providers text area. A new window will appear.
  4. In this window, add from left to right the databases and the Runtimes you want to add to the profile.

The created profile will be automatically usable in the selection combo box under the main menu.

You can check the Default Profile box if you want to use the Profile as default for users that doesn’t have any profile selected.

Tip: All Runtimes and All Log Databases are virtual providers allowing to dynamically gather data from all configured Runtimes or Log Databases.

Defining statistics

Statistics can be added or removed in the Statistics tab.

Every numeric variable can become a statistic. These statistics will appear in the statistic view.

Defining preferences

In the Preferences tab, you can manage and configure Analytics behaviors.
The following properties are available:

Property Default Description
Display builds under Packages false If true, every build will be displayed under its Package node. If false, builds will only be displayed under their respective Specification node.
Analyze Runtime after building new version false If true, the Runtimes associated to a specification will be analyze automatically when building a new version.
Enable check connections on Configurations false If set to true, the connections of the Configurations specified in Deployment Managers can be tested through the ‹Check connections› right click menu.
Auto connect Runtimes true Analytics will maintain a connection to the Runtimes if this property is set to true. If the connection to a Runtime fails a new try is performed after the delay specified in ‹Runtime connection retry interval›.
Runtime connection retry interval 60 seconds Time to wait before retrying to connect to a Runtime that Analytics failed to contact.
Auto refresh enabled by default true Set it to true to enable auto-refresh on Session Reports.
Session refresh Frequency 60 seconds Refresh delay of Session Reports when Auto-Refresh is enabled.
Hide Actions in Session Reports false If true, all the actions that are usually shown under the sessions will be hidden and not loaded when retrieving sessions. This provide better performances when navigating in sessions having hundreds of actions.
HTTP Sessions timeout 5 minutes Analytics session timeout. If no operations are performed during this delay, the session will be closed.

Managing Sessions

Defining Session Reports

Session Reports are used to gather, filter and visualize a list of sessions based on the criteria defined by the user.

Creating Session Reports

To create a new Session Report:

  1. Right click in the Public Session Reports topic in the navigator view .
  2. Choose "New Session Report"
  3. Give a name to the Report
  4. Modify the criteria, as explained below
  5. Save and click on the Refresh button

The sessions that meet your criteria will appear in the table.

My Session Reports topic can be used to create Session Reports only visible by the current user.

Auto refresh

If you enabled auto refresh mode in the Preferences, the session report will be refreshed periodically using the specified delay.
You can then manage this mode on each session reports by clicking on the auto-refresh button.

Icon Description
Auto refresh is started
Auto refresh is paused

Modifying criteria

Here are the criteria that you can choose to filter your sessions:

Standard settings

Note: If you select the Days before criteria, the To field isn’t useful.

Advanced settings
Criteria Description
Name Session’s name or name pattern. You can use the ‹*› sign to give a name pattern.
Configuration Sessions with the specified Configuration(s) will be displayed.
Runtime Sessions executed with the specified Runtime(s) will be displayed.
Guest Host Sessions with the specified guest host(s) will be displayed. The guest host is the hostname of the machine on which the session has been executed.
Session Id Sessions with the specified Id will be displayed.
Group By Group the sessions according to certain fields: Status, Name, Runtime, Guest Host, Execution Mode, Launch Mode, Configuration. This will open a window in which you can add the group fields.
Standalone Child Sessions If true, the child sessions will be displayed in the list of sessions as if they were standalone sessions.
Status List of statuses you want to display in the session list.
Duration Only the session fulfilling the specified duration will be displayed.
Execution Mode Sessions with the specified Execution Mode(s) will be displayed.
Launch Mode Sessions with the specified Launch Mode(s) will be displayed.
Package Id Sessions with the specified package Id(s) will be displayed.
Max Sessions Maximum number of sessions displayed.

Tip: In the Group By box, the field can be ordered. That means that you can group the sessions by name and then by status, or other arrangements.


Status Description
Prepared Prepared but not executed sessions.
Running Running sessions.
Executed Executed sessions.
Error Sessions in error.
Killed Sessions killed by the user
Dead Dead sessions, that is sessions that never finished and are considered as dead by Stambia Analytics

Launch Modes

Launch Mode Description
Designer The session has been executed from the Designer.
Schedule The session has been executed automatically by a schedule.
Web Interactive The session has been executed from Analytics.
Engine Command The session has been executed from the Runtime Command utility (E.g. Using the ‹execute delivery› command).
Command Line The session has been executed from command line (E.g. with startdelivery.bat).
Web Service The session has been executed from the Runtime’s REST or SOAP web services.
Action The session has been executed from the ‹Execute Delivery› Process Action.
Restart The session has been restarted.

Execution Modes

Execution Mode Description
Memory The session has been executed in memory in the Runtime.
Autonomous The session has been executed outside of the Runtime.

Modifying the table columns

By Right-clicking on the sessions table header, you can choose the columns you want to display.

Note: The modifications are saved for each user through cookies. If the cookies are not allowed, the modifications will be discarded when the user exits his web session.

The views

Around the sessions table, some views are useful to retrieve knowledge about the session when you click on it in the sessions table.

The session detail

Entering a session detail

You can enter into a session’s detail by double-clicking on the session’s row in the sessions table.

This will open a new window, in which the session execution tree will appear.

The tree can be opened.

The views

Clicking on each node of the tree will synchronize the information displayed in the different views.

Modifying the displayed information and the session status

In the upper-right side of the session detail window, buttons can be pressed in order to select the information displayed in the tree.

Visualization of sessions

The Charts tab

The Charts tab gives some graphs that summarize the statistics of the sessions.

The Timeline tab

The Timeline tab shows sessions' executions over time.

To navigate in the timeline:

To zoom in and out:

To view the information of a session:

Timeline Legend:

Full line: Normal execution

Multiple blank separated lines: Same session executed in parallel.

Dotted lines: child sessions

Gradation: Sessions scheduled.
Analytics analyze the already executed sessions and estimate the time for future scheduled one’s.
The Fifty next schedules are shown.

Current time:

Restarting or stopping a session

To restart or stop a session there are two ways:

Getting the documentation on a Process

If the Deliveries have been built through a package including the documentation, all the sessions running with theses will be linked to the documentation.

In this case, the documentation is accessible at different locations:

Managing Runtimes

In the Navigator View , under the Runtimes topic , will be listed all the Runtimes defined in the parameters.
If the list is empty, check if a profile is selected in the combo box under the main menu.

Runtime detail

By a double-click on a specific Runtime, a new window will appear.

This window has several tabs:

Runtime Deliveries

A Delivery can be opened by a double-click on it. The opened view allows to execute, restart or delete a session for this Delivery.

A session list is automatically displayed, filtering on this Delivery.

The criteria can be modified in order to refine the session list.

A right-click on the Delivery in the navigator view allows to execute or define a new schedule.

Note: When executing Multi-Configuration Deliveries, a selection window will open to choose the Configuration to use.

Scheduling a Delivery

In order to schedule a Delivery:

  1. Right-click on the Delivery in the Navigator View
  2. Choose New Schedule
  3. A new window appears, allowing you to define the schedule.
  4. In this new window, each tab Second, Minute, Hour, Day, Month, Year should be filled according to the schedule you want to create.
  5. This will generate a sort of cron expression that will be sent to the Runtime when the schedule information will be saved.

Note: For Multi-Configuration Deliveries, a Configuration must be selected in the corresponding combo box.

Managing Deployment Managers


Deployment managers allow you to customize, configure and manage the deployment of the integration processes developed on the Designer tool.

A Deployment Manager will contain Packages, Deployment Specifications and topology information (connections, metadata configuration).

Creating a Deployment Manager

In the Navigator View , under the Deployments topic , will be listed all the Deployment Managers that have been created.

To create a new Deployment Manager:

  1. Right-click on the Deployments node in the Navigator View
  2. Choose New Deployment Manager
  3. Give a name and click on Finish

Deployment Manager View:

The arrows are used to navigate through the items with missing settings.

The Deployment process

In a Deployment Manager, you will be able to

Importing a Package

To import a Package:

  1. Open the Deployment Manager
  2. Click on the Import button
  3. Browse and choose a Package file, the extension of which is .pck

The package will be imported and attached to the Process node.
Different packages files can be attached to a same Process node, according to their unique identifier.
The default name used for the imported Package is the import date.

To import multiple packages at the once, simply make a zip archive containing all your packages and import it with the Import button
The packages must be at the root of the archive and only .zip files are allowed.

Organizing Packages

You can structure your Deployment Manager using virtual folders .
This allows to organize and arrange your packages under a folder tree.
To create a folder, click on the New Virtual Folder button.
You can create as many folder/sub-folders as you need.

Then, simply drag and drop your packages between folders to organize them.

Defining Configurations

You have to define the Configurations that will be used to configure the Delivery’s metadata.
To define a new Configuration:

  1. Click on the Configuration tab in the Deployment Manager
  2. Click on the Add button
  3. On the right side fill the Name field that will be the unique identifier of the Configuration.
  4. Don’t forget to save.

Note: The Configurations could be, for instance, PROD, PREPROD, or TEST.

Composed Configurations:

The Configuration can be configured to inherit from other existing Configurations with the Parents field.
To define a new Composed Configuration:

  1. Click on the button near Parents field.
  2. This will open a new Window in which you will select the desired Configurations.

Note: The order is important as it will define the inheritance order: the values of the lowest Configuration will be taken, if a value is not found, the value of the upper configuration will be taken, and so on...

Creating a Deployment Specification

Once you have imported a Package, and you have defined at least one Configuration, you will be able to create Deployment Specifications and configure the metadata.

To create a Deployment Specification:

  1. Right-click on the Process node
  2. Choose New Deployment Specification
  3. On the specification , specify one or multiple Configurations by clicking on the button near Configurations property.
  4. This will open a new Window in which you will choose the Configurations you want to associate to your Specification.

Note: # You can have multiple Configurations associated to a Deployment Specification. It offers the possibility to execute a delivery with different Configurations, useful for testing with different values, for example.
# Do not confuse this with a Composed Configuration, which is a single Configuration that inherits from other ones.

Configuring the metadata properties

Once the Deployment Specification is created and associated to one or more Configurations, you will need to configure the metadata properties on these specified Configurations.

  1. Click on the Deployment Specification.
  2. On the right part will appear the list of the metadata that you need to configure.

If the Error icon appears on property, you have to configure the metadata, because it has not been configured before.
If the Configuration icon appears, then the metadata is correctly configured.

Several Packages can share the same metadata. In this case, some metadata could already be configured due to a previous deployment work.

You can filter all properties which need to be configured by clicking on the error icon on the top of Configuration table, next to the text filter.

To define the metadata:

  1. Click on the property that you want to configure
  2. On the bottom part, the property will appear with its imported value. This is the value that has been exported from the design moment when the Package was created.
    1. You can keep the same value by clicking on the Configuration link
    2. Or you can define your own value by filling the text area
  3. Do this for each property that has the Error icon

Note: For composed Configurations, you can see that all the parents appear in this window. If a value is not set, the value from the parent will be taken.

Tip: Use the Initialize top button to set all the missing values to the default package values.

Remotely available deliveries

You can set a delivery as Remotely Available.
A Runtime configured to access to the Deployment Manager will fetch the latest version of the delivery before executing it.

  1. Click on a Deployment Specification.
  2. Check Remotely Available.
  3. Optionally, change the remote name, which by default is the process name.

Building a Delivery

Once all the metadata are configured, a Delivery can be built from the Deployment Specification.

  1. Right click on the Deployment Specification node , and choose Build Deliveries.
  2. This will create a new version of Delivery and place it under the Deployment Specification node.

Note that you can build Deliveries from any nodes (Specification, Process, Folder, ...) with right click and Build Deliveries.
This will create a Delivery for each child of the node.

Note The metadata configured on a built Delivery cannot be modified. If a modification needs to be done, update the Deployment Specification, and build a new version.

Tip: Click on the top Build All button to build Deliveries for the entire Deployment Manager.

Deploying Deliveries on the Runtimes

A version of a Delivery can be deployed on Runtimes.

To proceed, you’ll first have to associate one or more Runtimes to the Deployment Specification.

  1. Click on the Deployment Specification
  2. Click on the button near Runtime property.
  3. This will open a new Window in which you will choose the Runtimes you want to associate to your specification.

After associating one or more Runtimes, you can deploy Deliveries to them.

There are three ways to do it:

  1. Right click on the Delivery and choose Publish Delivery
  1. Right click and choose Publish Deliveries
  2. This will open a new Window in which you will select the Delivery to publish and on which Runtime.
  1. Right-click on the Delivery
  2. Choose Download Delivery

Note: You can only deploy the Delivery on a Runtime by a Publish operation if the Runtime is started (on-line) and accessible.

Tip: Click on the top Publish All button to publish all Deliveries of the Deployment Manager.

Defining Deployment Schemes

Deployment Schemes can be used to automate the configuration of Deployment Specifications.
A Scheme is simply a pre-configured Specification where you can define the Configurations, Runtimes, and options that must be used.
After defining a Scheme, you can choose to use it on the desired Deployment Specifications using the Deployment Scheme box.

Warning: When updating a Scheme, all the Deployment Specifications using it will be impacted.

To define a Deployment Scheme:

  1. Click on the Deployment Scheme tab in the Deployment Manager
  2. Click on the Add button
  3. On the right side fill the Name field that will be the unique identifier of the Deployment Scheme.
  4. Define the properties accordingly to your requirement: Runtime, Configuration, ...
  5. Don’t forget to save.

The ‹Use as default Scheme› property allows to specify that the Scheme must be used automatically on newly created Deployment Specifications.

The ‹Remote name mask› property can be used to define dynamically the remote name of the Specifications using the Scheme.
This allows to use the same Scheme on multiple Specifications by using the following masks:

Mask Description
[Scheme] Name of the Scheme.
[Package] Name of the Package.
[DeploymentSpec] Name of the Deployment Specification.

The masks will be replaced automatically with their values on the Specifications using the Scheme.

You can moreover use the Generate Schemes button to automatically create all the Schemes corresponding to the existing Deployment Specifications.
After clicking on this button, Analytics will generate the Schemes and let you choose if you want to use the newly created Schemes on the Deployment Specifications.

Managing Delivery versions and checking the differences

The current and default versions


If you import new versions of a Package you have imported before, the last imported Package will become the current used version of the Package .
A new icon will be added to specify that this Package is the one used to generate the Deliveries.

Delivery versions

If you create a new version of a Delivery, the last Delivery version you created will become the current version of the Delivery .
A new icon will be added to specify that this Delivery version is the last version.

Checking the differences

If there are differences between the Delivery metadata and the version of the Delivery, a warning icon will appear on the objects (tree nodes and metadata properties).

This is probably because a metadata has been changed before the Delivery was built.

You can check the differences between the built version of the delivery and the version deployed on the Runtimes. This is available if you defined Runtimes for this Delivery.

Under the current version node you will see the Runtimes on which different statuses can appear.
A warning icon will appear if a difference is found.
A question icon will appear if the difference is unknown.
A green checked icon will appear if the built Delivery and the deployed Delivery are correctly synchronized.

To check the differences:

Tip: Click on the top Analyze All button to analyze all the runtimes.

Restoring a previous version

It is possible to restore a previous version of a Package or a Delivery.

The default green icon will appear on the element you have selected.