As we expand the deployment of Workflow Activities within the CampusNexus architecture, the number of host processes for workflows is now up to five.
Workflow Engine Host Processes
- Workflow Composer
- Nexus Windows Service
- CampusNexus Student web site
- Regulatory WCF web site
- CampusLink WCF web site
In this post, I’ll review each host and identify which type of events each host will source. As well as the method that each host uses for executing the various activities that are now available within the workflow composer.
When mentioning “Legacy” activities, contracts or services I am referring to the contracts and workflow activities that were manually coded up to and including version 17.0 of CampusVue. These contracts and activities are in the Cmc.Nexus.Workflow.* namespaces. Current contracts for CampusNexus will be identified with the module name in the namespace (no “Sis” in the namespace). Activities are in the “Cmc.Nexus.ModuleName.Workflow” namespace.
The current deployment of the workflow composer and workflow execution engine supports both the legacy and the new CampusNexus contracts. Based on the host, the method (or transport) used for connecting the to the service will vary and is based on configuration.
Executing of a workflow within the composer is triggered by the user. By selecting “Run” or “Debug” from the toolbar.
- Services for legacy activities will be executed In Process. The workflow package contains all of the DLL’s necessary to execute the workflows locally.
- Services for the new, CampusNexus, activities will be executed via a WCF end-point. The end-point base address is configured in the CampusVue database in the SyRegistry table. Using a Wcf configuration module, the service interface is registered within the container to connect to the end-point whenever a request is made to the service.
Regulatory WCF Web Site
There is currently only one event being raised from within the Regulatory code. This is the ISIR Match Saved event.
- Services for the new, CampusNexus activities will be executed via a WCF end-point. The end-point base address is configured in the CampusVue database in the SyRegistry table. The base address stored is the address for the deployed Cmc.Nexus.Web site. Using a Wcf configuration module, the service interface is registered within the container to connect to the end-point whenever a request is made to the service.
- Services for legacy activities will also be executed via a WCF end-point. The end-point base address is the CampusLink.WCF site (stored in the SyRegistry table). Using a Wcf configuration module, the service interfaces for the legacy services are registered within the container to connect to the CampusLink WCF end-point whenever a request is made to the service.
CampusLink WCF Web Site
This site handles all of the “Saving” events from CampusVue. There is custom code added to CVue in specific areas that will raise the Saving event on entities.
- Services for legacy activities will be accessed In Process
- Services for the new CampusNexus namespace will be accessed via the Wcf Proxy
Nexus Windows Service
This is the original handler of events for Nexus. This Service Module Host listens for messages from the Sql Server database Service Broker queue. The messages are generated from database triggers and will raise the Saved event on the entities.
- Services for legacy activities are accessed In Process
- Services for the new CampusNexus namespace are accessed via the Wcf Proxy
CampusNexus Student Web Site
The CampusNexus Student Web Site (Cmc.Nexus.Web) will raise events for all services and entities being updated, inserted, created or deleted. This includes the invocation of the service from within the site as well as the invocation via a WCF end point.
- Services for the new namespace will be executed In Process. All services are published with the site.
- Services for the legacy activities will be executed via the Wcf Proxy
- There is also a special condition handled within this site. New services that re-use CampusLink code will be remoted to the CampusLink WCF site. This is done by configuration within the Cmc.Nexus.Web site – the services to be remoted are specifically identified by the developers. When this occurs, the CampusLink WCF site is called using the new service interface and contracts. The implementation on the CampusLink side uses the new interface and then can re-use any CampusLink processes as needed.
Example using ITaskService
var task = context.GetValue(Task);
var taskService = ServiceLocator.Default.GetInstance<ITaskService>();
var response = task.Id.CompareTo(0) == 1 ?
taskService.Update(new EntityServiceRequest<TaskEntity>(task)) :