Skip to main content
Jump to: navigation, search

Stardust/Knowledge Base/Deployment/PossibilitiesforProductionDeployment


There are three aspects to be considered when deploying a Stardust runtime environment:

  • Deployment Variants
  • Runtime Administration
  • Stardust in a Clustered Environment

Deployment Variants


  • Lightweight Spring-based environment
  • JMS can be enabled
  • Useful for Continuous Integration

Managed Environment

  • Spring-managed
  • JMS enabled
  • JEE component
  • Stateful / Stateless

Runtime Administration – Application Server

  • Stardust process engine relies on the application server infrastructure for the following:
  • Transaction Management
  • Data Source Pooling (Audit Trail)
  • JMS Resource Provider
  • Clustering, Load Balancing and Failover capabilities

Transaction Management

  • Transactions are bound to Global Transaction via JTA managed by the container.
  • JTA transaction monitoring of application server can be utilized.

Data Source Pooling

  • Audit Trail Data Source is registered in application server and looked up via JNDI.
  • Data Source pooling is managed by the container.
  • JDBC connection monitoring of application server can be utilized.

JMS Resurce Provider

  • Connection Factory as well as required Queues are registered in application server and looked up via JNDI.
  • Connection Pool and Queue monitoring of application server can be utilized.

Clustering, Load Balancing and Failover capabilities

  • Stardust completely relies on the capabilities of the underlying application server for these features.
  • This also includes the monitoring capabilities a certain application Server provides with regards to load Balancing and failover.

Runtime Administration – Database Server

AuditTrail Database

  • Contains process model and process runtime and history information.
  • Continuous maintenance of DB tables and indexes required.
  • Monitoring via SlowQuery logging.
  • Analysis via Explain Plan execution.
  • Regular calculation of statistics recommended.

AuditTrail Archive Strategy

  • Archive strategy should be in place from day 1.
  • 2 Level Archive strategy
  • Level 1: Production AuditTrail data older than X days is loaded into an archive database.
  • Level 2: Archive AuditTrail data older than Y days is completely purged.
  • Archive strategy depends on the business requirements and mandatory retention period.
  • Stardust provides a command line tool (sysconsole) for the Archive process.

Runtime Administration – Model Deployment

Model Deployment

  • Version vs. Overwrite.
  • Deployment via console command line tool, API or Administration Portal.

Deployment Strategy (Production Environment)

  • Process models should always be versioned.
  • Use Valid From date for new model deployments.
  • Use the console command line tool for model deployments.
  • Stop Stardust daemons prior model deployment.
  • Archive dead (unused) process models on a regular basis.

Runtime Administration – Stardust Daemons

Stardust daemons are used to:

  • Trigger processes based on a certain time interval (Timer Trigger) .
  • Trigger processes based on incoming mails into a certain inbox (Mail Trigger).
  • Trigger actions based on certain time-based events (Event Daemon).

Stardust daemons are background threads that:

  • Can be started and stopped via console command line tool.
  • Can be automatically monitored via a Daemon Watchdog.
  • Need to be stopped during model deployment

Stardust Daemon Watchdog

  • Checks health status of daemons periodically.
  • Restarts daemons in case of an abnormal crash.
  • Is needed to enable failover capability of Stardust daemons.

Stardust in a clustered environment


  • Stardust relies on clustering capabilities of the underlying application server.
  • The process engine as well as portals can be deployed on multiple nodes within a cluster.
  • There is no need to synchronize state between the nodes.
  • Single point of synchronization is the AuditTrail.

Exception: Process Model Deployment

  • Model cache is only updated on the node where the deployment is applied.
  • All other nodes need to be re-initialized (console command line tool).
  • Use of Valid From date to make sure, each node relies on the same model version at the same time.

Exception: Stardust Daemons

  • Daemons need to be started on one node only.

Load Balancing

  • Stardust supports Sticky Session load balancing for HTTP requests
  • JMS load balancing is possible using distributed queues for
  • CarnotApplicationQueue
  • CarnotSystemQueue


  • Stardust relies on failover capabilities of the underlying application server.
  • Stardust needs to be deployed as EJB-component or Spring-managed with JMS enabled.
  • Stardust queues must be clustered.
  • Daemon Watchdog enables failover capability for Stardust daemons.

Back to the top