How the DCS Runtime Injects a Transparent Process into a Service
A transparent process lets you implement functionality that can run automatically when a client application invokes an operation in a service or when an operation returns a response to a client application.
A transparent process can hold and persist state between operations. An administrator configures a transparent process by defining a pipeline, and then associating the pipeline to a DCS operation. When the client application invokes the DCS operation (known as the base operation), the DCS runtime triggers the pipeline. The actual point at which a transparent process in a pipeline runs is determined by the events that it responds to. When a transparent process in a pipeline runs, it receives the request and response messages that are passed between the client application and the operation. The transparent process can examine these messages and transform them.
You use the DCS Management Console to configure the transparent service pipeline and when the transparent workflow runs. Therefore, the base workflow has no dependency on the transparent workflow. A transparent workflow lets an administrator insert additional functionality into an operation without requiring any changes to existing client applications or to DCS services.
Transparent Workflow Events
When you create a workflow for a transparent process, you configure the WaitForTransparentProcessEvent activity to wait for one of five events. The event that the activity waits for determines how the transparent workflow runs. The following table lists the events that the activity can wait for and describes when the base activity sends the event.
Event name |
Description |
|---|---|
Started |
The DCS runtime raises the Started event after invoking the base workflow, but before the base workflow executes. The transparent workflow runs, and then passes a response message back to the DCS runtime. When the DCS runtime receives the response message, the base workflow executes as usual. |
EventReceived |
The DCS runtime raises the EventReceived event when the base workflow receives a message after the initial request message. When the base workflow is a conversational workflow, you can configure your transparent workflow to run every time that the workflow runtime receives a request message before the message passes to the base workflow. This lets you modify the incoming message sent to the base workflow. |
EventProcessed |
The DCS runtime raises the EventProcessed event every time that the base workflow sends a SendResponse message. When the base workflow is a conversational workflow, you can configure your transparent workflow to run every time that the base workflow sends a response message before the message passes to the client application. This lets you modify the outgoing message sent from the base workflow. |
Exception |
The DCS runtime raises the Exception event when the base workflow operation encounters an exception. The transparent workflow runs after the exception is raised, and then sends a response message back to the base operation workflow for processing. |
Ended |
The DCS runtime raises the Ended event when the base workflow completes. When the base workflow sends its final response message, and the base workflow runtime terminates, the transparent process executes before the response message is sent to the client application. |
When the DCS Runtime receives an event, the transparent workflow functionality executes if it is waiting for that event, progressing through the sequence of activities that you defined until it reaches the SendTransparentProcessResponse activity. At this point, the transparent workflow sends the response message to the DCS runtime, informing the runtime that the base workflow can continue. The transparent workflow then terminates.
For more information about the WaitForTransparentProcessEvent and SendTransparentProcessResponse activities, see Activities for Building DCS Business Workflows.
Note
The DCS runtime only raises the EventReceived event for secondary request messages received after the initial request message that triggers the workflow runtime. When the initial request arrives, the DCS runtime raises the Started event. The runtime does not raise the EventReceived event for that message. However, any subsequent request messages raise the EventReceived event.
In addition, the DCS runtime only raises the EventProcessed event on SendResponse activities that do not signify the end of the workflow procedure. If the SendResponse activity is the final activity in the base workflow, DCS raises the Ended event. If there are activities in the base workflow following the SendResponse activity, DCS raises the EventProcessed event instead, and base workflow execution continues.
Transparent Process Messages
A transparent process intercepts the request and response messages passing between a client application and a service instance. When you write a workflow for a transparent process, you use the TransparentProcessRequestMessage and TransparentProcessResponseMessage classes that DCS provides in the Microsoft.ConnectedIndustry.ProcessExecution.Common.dll assembly. A transparent workflow contains the standard Request and Response properties to refer to these messages.
The TransparentProcessRequestMessage and TransparentProcessResponseMessage types contain a property of type Message, which is populated by the DCS runtime with the actual request or response message from the client application or the service instance. The Message type is the super-type of all DCS messages. This property lets you access the messages that are passed to or from the base service and modify those messages as if they were sent to the transparent process directly.
To access the incoming request and response messages that are passed to the base workflow, you use the Request.Message and Response.OutgoingMessage properties of the request and response messages or the transparent process respectively.
See Also
Activities for Building DCS Business Workflows