Stardust/Knowledge Base/Deployment/PossibilitiesforProductionDeployment

Introduction

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

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

Deployment Variants

Standalone

• 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

Clustering

• 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

Failover

• 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.