A Glossary of Opalis Components and Terminology

I was compiling a glossary of essential Opalis terms earlier this year, and now notice I still don’t see a very complete list anywhere in the blogosphere. Here’s a quick reference pulled together from various sources (blogs, conferences, webcasts (Charles Joy), product documentation, etc). This list consists of 1) Components and 2) Terminology. I’ll like start doing some blogging on Opalis in coming months, so this can serve as a useful point of reference as we dive into various data center scenarios. I’ve also included some useful links I found to the Opalis help files online…


Opalis Integration Server includes the following components:


The Data store is the Oracle or SQL Server database where configuration information, Policies, and logs are stored.


The Opalis Integration Server Client enables you to build, deploy, and maintain your policies.

  • Designer Console – As you might guess, this is the console where you design, construct and edit workflows
  • Operator Console – A web-based enables you to see which Policies are currently running, view their real-time status, and start or stop them from a browser console interface.
  • Policy Testing Console – The tool used by designers to test Policies that are developed in the Client before they are deployed.


  • Action Server – The engine that runs Policies. Action Servers communicate with the Datastore. Action Servers do not require a Management Server to be online to be able to run Policies. You can deploy a single Action Server or multiple ones.
  • Management Server – The central manager of Clients, Action Servers, Policies, the Policy Testing Console, and the Self Monitoring functionality. The Management Server deploys Integration Packs to Action Servers and Clients, deploys Policies to Action Servers, and acts as a communication link between the Clients, the Action Servers, and the Datastore.
  • Action Service Watchdog – Makes sure the Action Servers are up, have connectivity to the database, etc. Also the component responsible for determining if a particular workflow (or step within a workflow) is taking longer than it should.
  • JBoss Service – This is the service that runs the Operator console in this release (6.3)
  • Remoting Service -   The Deployment Manager uses the Opalis Remoting Service to install and uninstall Integration Packs, Hotfixes, Action Servers, and Clients on remote and local machines. It is also used for querying machines about what is installed on them.


  • Aspt.exe – The Action Server Policy Throttling command line utility (aspt.exe) included with the Opalis Integration Server Management Server, which can be used to increase / decrease the value of allowed concurrent policy instances
  • Check In / Check Out – When you have finished updating a Policy, you must check in your changes to commit them to the Opalis Datastore. This is the way Opalis integration servers save the work.
  • Counters – Global integer variables you can use within policies, with the ability to modify the value within a policy, such as an incremental number of attempts.
  • Databus – a mechanism used within Opalis to pass information from one object in a Policy to the next object. The data flowing along the path of the workflow is called “Published Data”, and each subsequent object in the policy adds its own data to the Databus. As you get further along in the workflow, more data becomes available.
  • Deployment Manager – What you use to view your Opalis Integration Server infrastructure and deploy Action Servers, Clients, Integration Packs, and Hotfixes from one place.
  • IPs vs Foundation Objects – Integration Packs are collections of custom Objects that are specific to a product (like OpsMgr, SCSM, etc). Foundation Objects are what you get with a clean install. There’s something like 100 of these that mimic various OS tasks, processes…a lot of different basic activities that could be required in different policies. They also provide the ability to communicate with other systems over common protocols, such as SOAP (for web services).
  • Ad hoc vs MonitorsAn Ad-hoc job is one started on demand by an operator, designer or even another job as needed. A monitor job on the other hand with instantiate an instance of itself, waiting for a specific condition or criteria trigger further action. Monitors are pretty often used to start a workflow.
  • Global Settings vs Global Configuration – A Global Setting would be a setting accessible to any object in the system. Examples include a named variable, log file name, common schedule, etc.  Global Configuration will be specifically for an integration pack to provide access to a target system, like where is the OM server, who do we login as, etc.
  • License Manager – This is what you use to import a license when you setup Opalis. Something you wont use very often.
  • Objects – The individual actions within a policy, available within the Client Objects Palette.
  • Pipelining – A term used to describe the workflow process of moving from one object to the next in the Policy based on links between the objects and conditions placed on the links.
  • Policy vs Workflow – Workflow is the term that replaces ‘Policy’ in Opalis. Policy is a term that was already in use at MS in another product, so the Opalis team had to change. When you see ‘Policy’, think ‘Workflow’. So Policies are Workflows that are created and used in Opalis. They will always contain only one starting point, but can contain multiple branches, actions and stopping points.
  • PolicyModule.exe – The executable instantiated by the Action Service to get the job done. The PolicyModule contains the logic for the object’s workflow execution. It is started when the Action Server starts the Policy, and is terminated when the Policy is stopped. Each Workflow runs in its own PolicyModule.
  • Publish vs Subscribe – Publish is something that happens automatically (part of the publish / subscribe data bus). Published Data is the data resulting from each object in a policy. As a designer, you choose what from the publish bus you want to use in your workflows. Your policies can subscribe to it and use it in their configuration. As you get further along in the workflow, more data becomes available. What types of data is available depends on what types of objects are used in the workflow.
  • Schedules – Global settings that allow you to define a set of date/time criteria for use within a policy. Schedules can be used to define when a policy will run an action, or when it cannot run an action.
  • Trigger – Causing a Policy object to activate, either by satisfying a monitor condition or by linking to a previous object which has already run.
  • Variables – Global values that can be used in policies to define often-used settings, such as directory paths to common files, server names, or other strings.

More Info on Opalis

The number of Opalis samples on the net is growing every day.

0 thoughts on “A Glossary of Opalis Components and Terminology

  1. Wilson

    Hi Pete.

    My company is thinking about using Opalis, I have to evaluate the tool. I have a problem, apparently I can not use opalisremotingservice Opalis because the service is not running on the server since it apparently is not even installed, how I can run or install this service?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.