• Processes, Tasks, and Fields,
• Documents and Reports,
• Matters, Matter Processes, and Matter Tasks,
• Lookup Tables,
• Stored Procedures,
• Active Server Pages, and
• Custom Components

Each Aspen Workflow tables includes a SubscriberID column.  The SubscriberID is populated by Aspen Workflow import or export routines, and it is the responsibility of these routines to guarantee the uniqueness of the SubscriberID across all Aspen Workflow installations.  Aspen Grove strongly recommends the following format to SubscriberIDs:

<website>-<database>-<table>-<primary key>

Website:  Internet standards require that every publicly accessible website have a unique domain name.  Leveraging this unique name avoids introducing a customized unique naming scheme, and ensures that SubscriberIDs can be traced back to their originating system without external references.

Database:  for websites that support multiple Aspen Workflow installations (such as demo.aspengrove.net), including the database name as part of the SubscriberID enables fully qualifying the Aspen Workflow installation.  In the rare event of a single website pointing to multiple data servers, with identical database names on the different data servers, Aspen Grove recommends qualifying the database portion of the SubscriberID with <server.database>, rather than simply <database>.

Table:  the table component of the SubscriberID represents the type of component being subscribed to.  This is not strictly related to database tables; for instance, the table component might be stored procedure or filename. 

Primary Key:  the primary key of the component being subscribed to.  For database rows, this is typically the identity column.  For a file, it is typically a relative URL.  For a stored procedure, it is typically the stored procedure name.  In any event, it must uniquely identify the component among all similar components in a single Aspen Workflow installation.

Sample SubscriberIDs might include:

• demo.aspengrove.net-litigation-process-12

• www.ipworkflow.com-ipworkflow-task-42

• assessireland.aspengrove.net-document-322

• eap.aspengrove.net-storedprocedure-lVendorProvider

• wellsfargo.aspengrove.net-file-/custom/reoSummary.asp

A subscribed component may be updated by importing a subscribed component, and may not be updated via the standard Aspen Workflow interface.  This prevents used from accidentally modifying a subscribed component, thereby destroying the integrity of a subscribed component’s behavior.

If an expert Aspen Workflow administrator wishes to modify a subscribed component via the Aspen Workflow standard interface, she must execute the pSubscribeBreak stored procedure.  This will set the SubscriberID of a component to NULL, and the Aspen Workflow interface will then allow normal updating of the component.  The standard Aspen Workflow interface provides a link to a page that calls pSubscribeBreak, after warning the user of impending doom.

For non-subscribed components, the SubscriberID field will be blank.  If a user enters information into the SubscriberID field that does not match the SubscriberURN system default, subsequent updates will treat that component as subscribed.  If this is done by accident, simply break the subscription as described in the preceeding paragraph.

• Development and production environments for the same processes,
• Purchasing and maintenance of industry standard processes, and
• The ability to roll back to earlier states.

Aspen Workflow’s Process, Task, Field, Process Task and Task Field tables include a SubscriberID column that uniquely identifies the external source of the data.  Components with a SubscriberID cannot be modified directly by the Aspen Workflow user interface without a “subscription break”, or removal of the SubscriberID.

Example:           Development vs. Production Environments

Acme Catering has built a “Wedding” process in a development database, and wishes to roll the new process out to a production environment.  In the production database, from Design > Processes, click on the “Subscribe to a Process” icon, and use the Subscriber Wizard to copy the Wedding process from the development environment.

Once the Wedding process has been copied into the production database, administrators will not be able to change the process because it is subscribed from the development environment.  Changes must be made in development, and the production database must be updated from the subscribed system.  To update a subscribed process, navigate to Design > Processes > Wedding, and select the Subscription Update icon.

Example:           Purchase of an Industry Standard Process

Acme Catering decided to institute customer surveys following weddings.  Rather than reinvent the wheel, Acme decided to purchase Aspen Grove’s standard Customer Relationship Management (CRM) process.  From Design > Processes, the Subscription Wizard was used to download the CRM process from Aspen Grove’s site.

These same tables include mirror History tables used to track previous revisions of the data.  This is particularly useful to track changes to business logic deployed in javascript.  Each time one of these workflow components is updated, a snapshot of the original state of the component is stored in the history table.  Administrators can thus review the change history of any workflow component, rolling back to earlier states if required.