Extending Processes using .NET

Neuron ESB ships with over 40 Process Steps that provide a range of functionality and productivity when building complex Business Processes. However, it is impossible to anticipate all the capabilities and scenarios that may need support across industries and businesses. Neuron ESB provides several methods to extend Business Processes using the .NET-programming model. This provides the flexibility to accommodate the need for the inclusion of customized business rules, logic or the use of third party .NET based assemblies. These methods include:

• .NET Language Code Editors
• Referencing .NET Assembles
• Custom Process Steps

These methods are not mutually exclusive, all of which may be used in a Business Process.

.NET Language Code Editors

Neuron ESB provides .NET Language Code Editors that permit developers to write Microsoft C#/VB.NET .NET code within a Business Process to execute business logic, manipulate a message, or call out to externally developed code or resources. The .NET Language Code Editors are exposed in the following two ways within the Business Process Designer:

• Modal Code Editors – Process Steps that expose a Code Editor for message parsing or returning Boolean expressions.
• Modeless Code Editors – Language centric Process Steps that expose a Code Editor that provide a full .NET programming experience

Modal Code Editors (Process Steps):

• Publish
• Decision
• Parallel
• Split
• For
• While

Modeless Code Editors (Process Steps):

• C#
• C# Class
• VB.NET

The Neuron ESB .NET Language Code Editors allow developers to embed C#/VB.NET in Business Processes. They support all the .NET 4.x language enhancements and intellisense as well as the following features:

• Line numbering
• References to assemblies or inherit referenced assemblies applied at the Business Process level
• Zooming
• Indenting
• Formatting
• Compilation Errors

The .NET programming code entered into the editors is serialized into the XML file that represents the Business Process within the Neuron ESB solution. This code is dynamically compiled at runtime the first time it is used by the Partys instance or after it has been updated.

The Code Editors are preconfigured with the following DLL references.

• Neuron
• Neuron.Pipelines
• Neuron.Esb
• System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• System.Data.DataSetExtensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• System.Runtime.Serialization, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
• **System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
• Newtonsoft.Json, Version=8.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
• Microsoft.CSharp, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Developers may reference other .NET Assemblies from the Code Editor. .NET Assemblies that are referenced must be in the Global Assembly Cache (GAC) or, in the Neuron “instance” directory with the other Neuron Assemblies or in the Probing Path of the Neuron ESB runtime.

The Code Editors are preconfigured with .NET programming using statements for some of the referenced .NET Assembly namespaces, specifically:

• using System;
• using System.Collections;
• using System.Collections.Generic;
• using System.Collections.Specialized;
• using System.Data.DataSetExtensions;
• using System.Linq;
• using System.Xml.Linq;
• using System.Xml;
• using Neuron.ServiceModel;
• using Neuron.Pipelines;
• using Neuron.Esb;
• using Newtonsoft.Json;
• using Newtonsoft.Json.Linq;

Any time a class is used from a namespace that has not had its using statements preconfigured; the fully qualified name of the class must be used.

Modal Code Editors

These are used by some Process Steps to assist in parsing messages or setting properties required as part of their configuration. All Modal Code Editors expose a method signature that passes a pipeline context object, containing the ESB Message to the user:

PipelineContext<ESBMessage> context

The Pipeline Context object represents the Business Process instance and is used to access several things at design time and runtime including the existing Neuron ESB Configuration, Environment Variables, Properties, Party, as well as the current message being processed.

The actual method signature may vary between the specific process steps.

In Figure 41 below, the Code Editor is opened by clicking on the ellipsis button of the Condition property of the While Process Step. The C# .NET code in Figure 41 returns a Boolean value at runtime to determine if the condition of the While loop has been met.

A more complex .NET programming code sample is displayed in Figure 42. This sample would be used within a Split Process Step to use C# code to split an inbound batch message into its individual constituent messages.

Modeless Code Editors

Modeless Code Editors are used in the C#, C# Class and VB.NET Process Steps to expand the overall code writing experience. They have features that the Modal Code Editors lack such as:

• Expanded Toolbar
• .NET Debugging Support
• Tabbed Interfaces

To add/edit code, drag the Process Step onto the Business Process, right click on the Process Step and select Edit Code from the context menu as shown in Figure 43. This will open the Editor into a Tabbed Window alongside the Business Process.

Expanded Toolbar

This provides developers access to common tasks such as undo, comment, format, indent, delete all breakpoints, add assembly references, display line numbers, etc., Figure 44.

.NET Debugging Support

Breakpoints can be added on a specific line of C# (within the C# or C# Class Code Steps) and VB.NET Code Step. Breakpoints will cause the Neuron ESB debugger to stop on the specific line when it hits, similar to what developers experience within Microsoft Visual Studio. Once broken into the debugger, a modified Toolbar (Figure 45) will appear allowing the user to continue, step over or stop the debugging process. While in Debug mode, developers can view the state of context and process within the Watch Window.

A Compile Window on all the Code Steps allow users to see the design time compile error, line number and column where the error is occurring as shown in the C# Code Editor Image below, Figure 46:

Tabbed Interfaces

The C#, C# Class and VB.NET Process Steps open into the same Modeless Tabbed Dialog view that Business Processes use (see Figure 46 above). Multiple Code editors (C#, C# Class and VB.NET) can be opened side by side in their own tabs, allowing users to navigate between Code Editors and Business Processes

Language.

.NET Language Process Steps

The .NET Language Process Steps are useful when one of the built-in Neuron Process Steps does not offer the functionality desired. They can be used to create custom processes without having to create custom externally developed and maintained code. Users can choose between the C#, VB.NET and C# Class Process Step.

C# Process Step

This is commonly used when there is no need to factor logic into multiple methods, share variables or add additional .NET using statements. The C# Process Step displays the following method signature that passes a pipeline context object, containing the ESB Message to the user:

void OnExecute(PipelineContext<Neuron.Esb.ESBMessage> context)
{
	// TODO: implement custom code here.
}

For more information go to the C# Process Step in the Process Step Reference Guide.

VB.NET Process Step

Writing VB.NET code within a Process is as simple as dragging the VB.NET Process Step onto the Process Designer, right click and selecting edit code from the context menu. Users will receive the same experience as provided by the C# Process Step. The VB.NET Process Step displays the following method signature that passes a pipeline context object, containing the ESB Message to the user:

Sub OnExecute(ByVal context As PipelineContext(Of ESBMessage))
{
	// TODO: implement custom code here.
}

For more information go to the VB.NET Process Step in the Process Step Reference Guide.

C# Class Process Step

The C# Class Process Step offers some advantages over the C# Process Step. The C# Class offers developers a way to refactor their code, reducing its complexity. It also allows developers to add using statements and define their own namespaces. The C# Class Process Step provides an existing template that developers can modify by changing the namespace and class names. Developers can add additional methods, static or non-static variables and new classes.

For more information go to the C# Class Process Step in the Process Step Reference Guide.

Code Editor API Samples

There are many cases where users either are required to, or will find a task easier to complete if the Neuron ESB .NET Language Process Steps are used. Following are samples of how to use specific APIs or complete certain actions in the Code Editors.

For example, within a Business Process users can check the direction of execution they are within. For example, users may want to do something specific if a Business Process is running on the On Publish event of a message versus the On Receive event. This can be accessed using the following C# within a Process Step:

if(context.EventSource == ExecuteEvent.OnReceive)
{
	// if receiving ...do something
}

The next example demonstrates retrieving the name of the current running process:

var processName = context.Pipeline.Name;

Working with messages

The data payload container within a Neuron ESB Business Process is the Neuron.Esb.ESBMessage class. The Code Editors are often used to manipulate the message payload. The Neuron.Esb.ESBMessage class has methods to set and retrieve data, encode data, set/get properties. Specifically:

• Neuron ESB Message Container
• Contains message body
• Contains header properties
• Contains methods
• Controls serialization of data
• Can contain custom properties

Common properties and methods to use for modifying the payload from a Neuron.Esb.ESBMessage are:

• FromString()
• FromXml()
• Bytes
• Text

While these properties and methods can be used to retrieve the payload from a Neuron.Esb.ESBMessage:

• ToXml
• ToXmlDocument
• ToXDocument
• Text
• Bytes
• Body
• GetBody<T>
• WriteMessage(stream)

The sample below demonstrates how to overwrite the data payload being processed by the Business Process with new data. It first shows how to access the data payload; convert it into its native .NET data type and then resets the current data payload with a new text message.

//retrieve the existing data payload as text
var data = context.Data.Text;
// If this is xml data, we can get an XmlDocument
var xmlDoc = context.Data.ToXmlDocument();
// or...get the XDocument reference
var xDoc = context.Data.ToXDocument();
// if this is JSON, get the dynamic JOBJECT
dynamic json = context.Data.ToJObject();
// alternatively, get the raw bytes
var bytes = context.Data.Bytes;
// Cast the data payload based on Body Type into its original .NET data type
if (context.Data.Header.BodyType != null)
{
	if (context.Data.Header.BodyType.Equals("text/xml"))
		context.Instance.TraceInformation( context.Data.GetBody<string>());
	if (context.Data.Header.BodyType.Equals("DateTime"))
		context.Instance.TraceInformation(context.Data.GetBody<DateTime>().ToString());
	if (context.Data.Header.BodyType.Equals("TestSerialization"))
		context.Instance.TraceInformation(context.Data.GetBody<TestSerialization>().Name);
	if (context.Data.Header.BodyType.Equals("Dictionary`2"))
		context.Instance.TraceInformation("Dictionary value: " 
		+ context.Data.GetBody<Dictionary<string, string>>()["myKey"]);
}
// overwrite the existing data payload
context.Data.Text = "new message";
context.Data.Header.BodyType = "text/xml";

Alternatively, cloning the message before overwriting ensures a new message id is generated for the final message, creating a parent/child relationship between the messages.

// cloning the message ensures the message id is changed and
// the parent id of the new message is set to the original
// message id
context.Data = context.Data.Clone(false);
context.Data.Text = "new message";
context.Data.Header.BodyType = "text/xml";

Neuron ESB message properties is an important way to add and retrieve out-of-band data. A message property lives with the ESB message but is not part of the payload. If set within a Business Process, it can be retrieved anywhere within the system; another Business Process, an Adapter, Service or even a Workflow Endpoint. If a message is audited, all custom message properties are (by default) audited with the message. Using message properties is one of three ways to maintain state during message processing with a Business Process.

Message properties are used when it is either not appropriate, practical or possible to modify the existing data payload. Facilities to provide out-of-band data is common in all protocols (i.e. HTTP and SOAP headers, TCP headers, MQSeries headers, etc.) to control custom business logic processing that is independent of the data payload.

// Set the customer purchase order number so that it
// can be accessed later in a Workflow or in
// follow up processes
context.Data.SetProperty("Org","PurchaseOrderNbr","P98098");
// Retrieve the purchase order number
var poNumber = context.Data.GetProperty("Org","PurchaseOrderNbr");
if(string.IsNullOrEmpty(poNumber))
	context.Instance.TraceError("The PO Nunber was not found");

The Neuron.Esb.ESBMessage and its custom properties can be used for dynamic routing scenarios. For example, the SOAP Headers can be retrieved from an inbound message received by a Neuron ESB Client Connector. Those values can be used to determine which Neuron ESB Topic to route a message to. The sample below shows how outbound SOAP Headers could be set:

// define the SOAP namespace and header name
var header = "https://www.neuronesb.com/samples/soapheaders" 
	 + "/" + "Route";
var routingTopic = "<Topic>MyCompany.Finance.Orders</Topic>";
// Add the value to the Neuron ESB SOAP Headers collection
context.Data.Soap.Headers[header] = routingTopic;

The SOAP client would in turn receive the custom header as part of their SOAP Envelope:

<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/">
	<s:Header>
		<Route xmlns="https://www.neuronesb.com/samples/soapheaders">MyCompany.Finance.Orders</Route>
	</s:Header>
	<s:Body></s:Body>
</s:Envelope>

The next sample shows how this same SOAP Header can be retrieved on an inbound SOAP based Client Connector and its value used to set the Topic property of the ESB Message.

// define the SOAP namespace and header name
var header = "https://www.neuronesb.com/samples/soapheaders" 
	 + "/" + "Route";
// Get the SOAP header
var routingTopic = context.Data.Soap.Headers.ContainsKey(header)?context.Data.Soap.Headers[header]:"";
if(!String.IsNullOrEmpty(routingTopic))
{
	// Load the xml doc
	var xmlDoc = new System.Xml.XmlDocument();
	xmlDoc.LoadXml(routingTopic);
	// set the topic with the value of the SOAP Header
	// that represents the service to route to
	context.Data.Header.Topic = xmlDoc.InnerText;
}

State Management

There may be cases where it is preferable to initialize some state (i.e. variable mechanism) in one part of a process and later use that state in another part of the process, or in a different process. In other cases, it may be desirable to share state between consecutive or concurrent executions of a specific Business Process.

There are four built in ways to store state between Process Steps, Business Processes and consecutive or concurrent executions of a specific Business Process.

• Push and Pop Process Steps
• Properties collection available on the Process Instance (i.e. context.Properties)
• State collection available on the Process Instance (i.e. context.State)
• Get and Set Neuron.Esb.ESBMessage Properties

For example, using the Parallel Process Step, each branch can generate its own message and its state information. After all the branches have executed, there would be a common need to inspect, modify or aggregate the information in those messages and do the same for any out-of-band state generated in the branches. There may also be a need to identify which branch generated which message. Out of the box, Neuron ESB uses the Properties Collection to provide these capabilities to developers. In fact, many Process Steps leverage Neuron.Esb.ESBMessage properties or the Properties collection so developers can dynamically set the properties of a Process Step at runtime or retrieve out-of-band results from the execution of the Process Step.

Push and Pop Process Steps

The first is the Push Process Step. The Push Step stores a copy of the current ESB message. The corresponding Pop Process Step restores theoriginal copied ESB Message. This allows developers to freely modify the message in any Process Step and later restore the original ESB Message using the Pop step.

These are used to preserve the entire ESB Message (payload, custom properties, etc.) between Process Steps called within an instance of a Business Process.

For example, a Business Process may need to call out to many endpoints with each endpoint requiring that the message body be transformed before it is called. For Request/Response type endpoints, a response message is returned to the process, overwriting the existing message body of the ESB Message. If another call to a different endpoint must be made, that service may require information from the original message. In this scenario, a Push step can be used before the first transformation and then a Pop step restoring the original information could be used before the second service call.

Internally, Neuron ESB is storing the message in a Stack, which is in turn is stored in the context.Properties collection i.e.

context.Properties["PushedContext"] = new Stack<T>();

Where T is:

PipelineContext<ESBMessage>

Since the ESB Messages are stored in a stack, the Push and Pop Process Steps can be called many times within a Process.

You can read more about the Push and Pop Process Steps in the Process Step Reference Guide.

Context Properties

The Properties collection of the context object can be used when more granularity and flexibility is needed to maintain state within a Business Process Instance. The Properties collection lives for the execution lifetime of a Business Process instance. It will NOT maintain state between the executions of different Business Processes (unless the Business Process is called from the Execute Process Step i.e. sub process model). It also cannot be used to share state between consecutive or concurrent executions of a specific Business Process. Hence, state stored in the Properties collection is not visible to any other part of the system or Business Process instances and will not show up in Neuron ESB Auditing.

State stored in the Properties Collection can be used when it is not preferable to have the state associated with the message, or when state is later required drive custom business decisions within the Process. Many of the Flow Control type of Process Steps use the Properties Collection to maintain state or modify its own behavior at runtime. Neuron ESB also uses the Properties Collection to maintain the Exception information that may be encountered during the execution of a Process.

The Properties Collection is represented by the .NET type:

ConcurrentDictionary<string, object>

Anything can be added to the collection and, upon retrieval, must be cast back into its original data type. In the example below, a copy of the ESB Message and the current DateTime is stored in the collection at the beginning of a Process:

// When a process starts, In a C# Process step, store the
// original ESB Message and the start time
context.Properties.Add("originalMessage", context.Data.Clone());
context.Properties.Add("startTime", DateTime.Now);
At the end of the process, both values can be retrieved and processed:
// At the end of a Process, In a C# Process step, retrieve the
// original message and start time and calculate total time in milliseconds
var esbMessage = (ESBMessage)context.Properties["originalMessage"];
var topic = esbMessage.Header.Topic;
var startTime = (DateTime) context.Properties["startTime"];
var currentTime = DateTime.Now;
var totalTime = currentTime.Subtract(startTime).Milliseconds;

State Properties

The State collection of the context object is very similar to the Properties collection; however its primary use is to serve as a caching mechanism between the consecutive or concurrent executions of a specific Business Process for a specific endpoint. For example, the first instance of a specific Business Process that executes could initialize the State (i.e. Cache), whereas consecutive executions of the same Business Process could retrieve the state. This can be very useful way to increase the performance of a Business Process if the information cached is rarely updated but expensive to retrieve.

The State Collection functions as a cache at the endpoint level i.e. whatever is hosting the Party instance that executes the Business Process. In Neuron ESB, Adapter, Service and Workflow Endpoints all host a Party. For example, if a Party associated with a specific Adapter, Service or Workflow Endpoint executes a Business Process, the State Collection will function as a cache for all messages processed by the specific endpoint for that specific Business Process.

Similar to the Properties Collection, the State Collection is represented by the .NET type:

ConcurrentDictionary<string, object>

Anything can be added to the collection and, upon retrieval, must be cast back into its original data type. Since other threads could also be accessing the object, using a Lock is good practice as shown in the example below:

Random rand = null;
// check to see if the global state has been initialized
// with the random object
if (!context.State.ContainsKey("Random"))
{
	lock(context.State)
	{
		if (!context.State.ContainsKey("Random"))
		{
			// create Random object because it does not exist
			rand = new Random();
			context.State.Add("Random", rand);
		}
	}
}
// get random object
rand = (Random)context.State["Random"];

Accessing the Configuration

The Configuration API of the context object returns the Neuron ESB ESBConfiguration object, which can be used at design time or runtime to access any entity and its respective data and properties. The Neuron ESB solution (represented by the ESBConfiguration object) is loaded into memory at startup. This can be used to retrieve stored documents from the repository (i.e. JSON, XSD/XML/XSLT Documents, Swagger, WSDL, TEXT, etc.), Credentials, Encryption keys, etc.

In the first example, a JSON template is retrieved at runtime and used to map existing values from an incoming message to create a final outgoing message.

Below is the original JSON message received and retrieved from the context.Data object using the ToJObject() method:

{
	"message": "Success. Lead Created",
	"data": {
		"SalesOwnerAccountUserId": "118527",
		"accountUserID": "8908B"
	}
}

Following is the code sample that retrieves the original JSON message, writes out its properties to the Neuron ESB log files and Trace Window and sets the HTTP API properties of the ESB Message to make a REST call.

// Get message fields from registration with SalesForce...JSON format
dynamic sfResponse = context.Data.ToJObject();
if(context.Instance.IsInfoEnabled)
{
	// Log the information to the Trace Window and Neuron Log files
	context.Instance.TraceInformation("-JSON SF Registration message data");
	context.Instance.TraceInformation(" JSON: ");
	context.Instance.TraceInformation(" JSON: Message =" + sfResponse.message);
	context.Instance.TraceInformation(" JSON: SalesOwnerAccountUserIdL = " +
		sfResponse.data.SalesOwnerAccountUserId);
}
// to update the SF account, set the method and headers
context.Data.Http = new HttpMessage();
context.Data.Http.Headers.ContentType = "application/json";
context.Data.Http.Method = "PATCH";
context.Data.Http.Headers.Add("Authorization", "");

Here is JSON body of the OrgAccountUpdateRequest template stored in the Neuron ESB Document Repository.

{
	"salesRepAccountUserID":{0},
	"auditAccountUserID":{1}
}

Next, the JSON template is retrieved from the Neuron ESB Document Repository by accessing the JsonDocs collection of the Configuration object. It is then mapped with values from the previously retrieved JSON message to create a new message by setting the context.Data.Text property.

// to create the new Update message and do our mapping, we retrieve a saved
// request JSON 'template" from the Neuron ESB repository
// which has format specifiers which we'll then replace
var updateTemplate = context.Configuration.JsonDocs["OrgAccountUpdateRequest"].JsonFormatString;
// Here's where we create the account update doc, mapping elements into
// our template and replace the existing ESB Message payload
context.Data.Text = string.Format(updateTemplate,
(string)sfResponse.data.SalesOwnerAccountUserId??string.Empty,
(string)sfResponse.data.accountUserID??string.Empty);

In this next example, the Configuration object is used to find a specific Endpoint and then print out all of its relevant properties to the Trace Window and Neuron ESB Log files. This checks the Endpoints collection first, which contains all Adapter Endpoints. If nothing is found, the Services collection is checked. There is a collection for every type of Neuron ESB Entity within a solution.

// define the name of the endpoint that you want to
// retrieve properties from. Endpoints are always preceded by
// the 'Zone' name, which by default is 'Enterprise'
var zoneName = context.Configuration.ZoneName;
var endpointName = zoneName + "/PaymentService";
// Here, we're accessing the Neuron ESB Configuration
// stored in memory either at runtime or design time
// The 'Endpoints' collection contains adapter endpoints
// whereas the 'Services' collection contains service endpoints
if(context.Configuration.Endpoints.ContainsKey(endpointName))
{
	var adapterEndpoint = context.Configuration.Endpoints[endpointName];
	// this writes to the Trace Window during testing or the Neuron
	// Log file at runtime.
	if(context.Instance.IsInfoEnabled)
		context.Instance.TraceInformation("Adapter Name: " + adapterEndpoint.AdapterName);
	// Loop through all the properties and print them out
	foreach( var prop in adapterEndpoint.Properties)
	{
		if(context.Instance.IsInfoEnabled)
		context.Instance.TraceInformation(" Endpoint Property: " +
			prop.Name + " : " + prop.Value);
	}
}
else
{
	// Check to see if this is a Service Endpoint
	if(context.Configuration.Services.ContainsKey(endpointName))
	{
		var serviceEndpoint = context.Configuration.Services[endpointName];
		// this writes to the Trace Window during testing or the Neuron
		// Log file at runtime.
		if(context.Instance.IsInfoEnabled)
			context.Instance.TraceInformation("Service Name: " + endpointName);
		// if 'RouteClientTraffic' is enabled, this is
		// Client Connector, a service hosted by Neuron ESB
		if(serviceEndpoint.RouteClientTraffic)
		{
			var webHookUrl = serviceEndpoint.ClientUrl;
			// this writes to the Trace Window during testing or the Neuron
			// Log file at runtime.
			if(context.Instance.IsInfoEnabled)
				context.Instance.TraceInformation("Client Service Url: " +
					webHookUrl);
		}
		// if 'RouteServiceTraffic' is enabled, this is
		// Service Connector, a service Neuron ESB calls
		if(serviceEndpoint.RouteServiceTraffic)
		{
			var serviceUrl = serviceEndpoint.AccessUrl;
			// this writes to the Trace Window during testing or the Neuron
			// Log file at runtime.
			if(context.Instance.IsInfoEnabled)
				context.Instance.TraceInformation("Service Url: " +
					serviceUrl);
		}
	}
	else
		context.Instance.TraceInformation("Does Not Exist: " + endpointName);
}

Accessing Environment Variables

Neuron ESB Environment Variables can be used for configuration of any adapter or service endpoint, database connection string or process step. However, developers can access the values of Environment Variables directly in Code Process steps within processes using the EnvironmentVariables collection of the context object. This allows environment sensitive information to drive custom business logic in a Business Process. For example, the username and password needed to access a service in a QA environment may be different from the set of credentials required in the Production environment.

In the following example, Environment Variable values are used to set HTTP Query variables and retrieve the correct Environment based credential to use to call the SalesForce REST API.

// to authenticate with salesforce, set the query string parameters for URL
// encoded form submission. Use Environment variables so nothing is
// hard coded and this can work seamlessly in other Deployment Environments i.e.
// Production, QA, TEST, STAGE, etc.
var salesForceCredentialName = "SalesForceCredential";
var salesForceCredential = context.EnvironmentVariables[salesForceCredentialName];
context.Data.Http = new HttpMessage();
context.Data.Http.Headers.ContentType = "application/x-www-form-urlencoded";
context.Data.Http.Method = "POST";
context.Data.Text = string.Empty;
context.Data.Http.Query.Add("grant_type",
context.EnvironmentVariables["SalesForce-grant_type"]);
context.Data.Http.Query.Add("client_id",
context.EnvironmentVariables["SalesForce-client_id"]);
context.Data.Http.Query.Add("client_secret",
context.EnvironmentVariables["SalesForce-client_secret"]);
context.Data.Http.Query.Add("username",
context.Configuration.Credentials[salesForceCredential].Username);
context.Data.Http.Query.Add("password",
context.Configuration.Credentials[salesForceCredential].Password);
context.Data.LocalPath = "services/oauth2/token";

Heres another example of using Environment Variables to access the Credential store of the Configuration object and storing the resulting username/password values into the Properties Collection so that it can be used in another part of the Business Process.

// Set the name of the Environment Variable to Retrieve
var envVarName = "Neuron-X-Authentication";
// The Neuron ESB Credential name is stored in an Environment variable.
// well use it retrieve the Credential from the Neuron ESB Security
// repository and use to build the authentication header that will
// be used for a Web Service call.
var credName = context.EnvironmentVariables.ContainsKey(envVarName)?
context.EnvironmentVariables[envVarName]:
string.Empty;
if(string.IsNullOrEmpty(credName))
	throw new Exception(string.Format(
		"There was not a Credential name value for the NeuronX Authentication assigned
		to the '{0}' Neuron Environment Variable.", envVarName));
// Retrieve the Security Credential from the Neuron ESB Configuration
var credential = context.Configuration.Credentials.ContainsKey(credName) ?
	context.Configuration.Credentials[credName] : null;
if(credential == null)
	throw new Exception(string.Format(
		"the '{0}' Credential was not found for the NeuronX Authentication assigned
		to the '{0}' Neuron Environment Variable.", credName, envVarName));
// If we want to use the value in a different Business Process
// we can store in the property bag
context.Properties["NeuronX-AuthenticationHeader"] =
credential.Username + ":" + credential.Password;
// OR We can just Set the HTTP Authentication header directly that
// the REST API is expecting using the HTTP API of the ESBMessage
context.Data.Http.Headers["X-Authentication"]=
credential.Username + ":" + credential.Password;

Using the Client Context

The Neuron ESB Client Context is created when a Neuron ESB Party is instantiated by an externally hosted application, or when a Neuron ESB Adapter, Service or Workflow Endpoint is started. The Client Context can be accessed directly within any Code Process Step by using the following syntax:

var clientContext = Neuron.Esb.Internal.PipelineRuntimeHelper.ClientContext;

The Client Context encapsulates all of the capabilities of the Party and exposes properties and references to internal objects that it must communicate with and use, some of which are:

Property/Collection/Method	Description
Session	Represents the Session ID (GUID) of the Party Instance. This is used for correlation purposes and uniquely identifies a Party instance connected to the runtime.
SID	Windows Security Identifier that represents the Windows Account the Party instance is running under.
BootstrapHost	The machine name hosting the Configuration service the Party communicates with. This is a Neuron ESB server.
ClientCredentials	The current Network Credentials the Party is running under
ConfigurationAddress	The URL address of the Neuron ESB Configuration service the Party is using to connect.
FailMessage()	A method for sending a message to the Neuron ESB Failed Message database
Machine	The name of the machine hosting the Party
OwnerSubscriber	The actual Party object. Can access all methods and properties like SendMessage(), etc.
PartyId	The name of the Party
Pipelines	The collection of Business Processes attached to the Party
RequestReplyTimeout	An integer representing the request/reply timeout in seconds that is used when calling through the Publish Process Step
TopicContexts	The collection of Topic connections that the Party is connected to.
Username	Windows Username represents the Windows Account the Party instance is running under.

In the following example, the Client Context is used to publish a message directly to the Finance Topics Transport, rather than using the Publish Process Step.

var topicContext = clientContext.TopicContexts["Finance"];
if (topicContext != null)
topicContext.Publish(context.Data);

Referencing External Assemblies

All the Modeless and Modal based Code Process Steps support allow users to reference any third party .NET assembly, any .NET assembly in the GAC (Global Assembly Cache) or any .NET assembly within the Probing Path of the Neuron ESB service runtime. The existing probing path setting is displayed below:

<probing privatePath="Adapters;Pipelines"></probing>

To use an alternative location, modify the Probing Path configuration in the following Neuron ESB app.config files:

• esbservice.exe.config
• neuronexplorer.exe.config
• esbhost.exe.config
• neurontestclient.exe.config

More information regarding how to set the Probing Path can be found here:
https://msdn.microsoft.com/en-us/library/823z9h8w(v=vs.110).aspx

If assemblies are referenced at the Business Process level (i.e. link to this), they are automatically added as references to every Modeless and Modal based Code Process Step in the Business Process.

Modal Code Process Step (i.e. Publish, Decision, etc.) references can be accessed directly using the Edit -> References menu on the Code Editor, Figure 53.

Whereas Modeless Code Process Step (i.e. C#, C# Class, VB.NET) references can be accessed directly using the File -> Manage Assembly References menu on the Code Editor, Figure 54.

Adding references to Code Process Steps functions exactly the same as when references are added at the Business Process level. Using external assemblies is a common practice when developing or using an existing set of common framework libraries to provide specific capabilities to a Neuron ESB Business Process.

Note:The GAC requires strong names and this can cause a traditional obstacle for developers who have turned on auto versioning for their assemblies. It is highly recommended that developersdo not use assembly versioningfor the dlls they plan to reference in the Code Editor.File versioning should be used in place of assembly versioning when versioning is desired.

Custom Process Steps

Neuron ESB provides over 40 Process Steps that provide a range of functionality and productivity when building complex Business Processes. However, it also provides the ability for users to build their own reusable custom Process Steps that can be registered and added to the existing Process Step Toolbox, Figure 55. This allows users to build out custom Business Processes that incorporate reusable custom Process Steps.

Besides using third party assemblies or writing code directly in the .NET Language Code Editors, custom Process Steps can also be used to extend the out of box functionality of the Business Process Designer. A Custom Process Step is a good candidate to use when there is a need to encapsulate proprietary code and business logic that can be driven externally by a custom set of exposed properties that direct its runtime/design time behavior. This may be a preferred approach where the designer of the custom Process Step needs to limit access or visibility of its source code and/or wants to ensure the business logic remains identical regardless of what user or Business Process uses it.

Custom Process Steps inherit all the base properties and features that all Neuron ESB Process Steps expose such as drag and drop, copy/paste, disable/enable, setting breakpoints, bindings, etc.

More information about Process Step properties can be found here: Process Step Properties

More information about Process Step features can be found here: Process Step Features

All custom Process Steps are developed using.NET 4.5 and by creating a Microsoft Visual Studio Class Library Project. They must be compiled into a .NET assembly to deploy. All custom Process Steps are .NET classes and must inherit from the CustomPipelineStep class and override the OnExecute() method as shown in the interface definitions below:

Class: CustomPipelineStep

Namespace:Neuron.Esb.Pipelines

Assembly:Neuron.Esb (in Neuron.Esb.dll)

Syntax:

[DataContract]
public abstract class CustomPipelineStep : PipelineStep<Neuron.Esb.ESBMessage>
{
protected CustomPipelineStep();
}

Class: PipelineStep<T>
Namespace:Neuron.Pipelines
Assembly:Neuron.Esb (in Neuron.Esb.dll)

Syntax:

[DataContract(Name = "{0}PipelineStep")]
[KnownType("GetKnownTypes")]
public abstract class PipelineStep<T> : IPipelineStep2, IPipelineStep,
IExpressionBindable, IDisposable
{
protected abstract void OnExecute(PipelineContext<T> context);
}

Depending on the User Experience required, Neuron ESB supports two types of custom Process Steps, Complex and Basic. The general difference between the two is that Complex custom Process Steps provide the developer more options for controlling the display of the Process Step within the Neuron ESB Explorer as well as its properties in the Property Page grid.

All custom Process Steps use the same method signature (i.e. OnExecute()) as used by the C# Process Step. Any object model, function or property that can be used in the C# Process Step can be accessed and used within a custom Process Step.

Process Step Types

Basic

The Basic model is the simplest way to build a custom Process Step. A Microsoft Visual Studio Class Library Project must be created and .NET Class must be added to it that will represent the custom Process Step Class. Additionally, a Resource File should be added if self-registration (decorating the class with the ProcessStepAtrribute) is used for deployment.

A Basic custom Process Step requires the following:

• A Class that inherits from CustomPipelineStep
• Must include the following assembly references
  • System.ComponentModel.Composition.dll
  • Neuron.dll
  • Neuron.Esb.dll
  • Neuron.Esb.XmlSerializers.dll
  • System.Runtime.Serialization.dll
• The Class that inherits from CustomPipelineStep must be decorated with
  • System.Runtime.Serialization.DataContractAttribute (required)
  • Neuron.Pipelines.ProcessStepAttribute (optional)
• Can optionally include a resource file (RESX)
  • Access Modifier must be set to public
• Can have either 1 or 2 icons (16 x 16)
  • RESX is needed to support multiple icons

Example

At minimum, a Basic model custom Process step will resemble the following sample:

using Neuron.Esb;
using Neuron.Esb.Pipelines;
using Neuron.Pipelines;
using System.ComponentModel;
using System.Runtime.Serialization;
namespace SimpleProcessStep
{
	[DisplayName("My Simple Process Step")]
	public class MySimpleProcessStep : CustomPipelineStep
	{
		protected override void OnExecute(PipelineContext<ESBMessage> 
		 context)
		{
			if(context.Instance.IsInfoEnabled)
				context.Instance.TraceInformation("MyCustomProcessStep called.);
		}
	}
}

In the example above, the attribute, DisplayName attribute (“My Simple Process Step”), is used for manual registration deployment to define the name of the Process Step as it will appear in the Process Step Toolbox, as well as the default name of the Process Step after it is added to a Business Process. If self-registration is used, the DisplayName attribute is ignored.

Once the Microsoft Visual Studio custom Process Step project has been compiled and deployed, by default the custom Process Step will appear in the Process Step Toolbox using the default Neuron ESB Process Step icon as shown in Figure 56.

The Default Icon can be replaced and a custom folder can be created to locate the custom Process Step within the Process Steps Toolbox when using manual or self-registration.

Using manual registration the neuronpipelines.config configuration file can be modified and a 16×16 icon (PNG format) can be copied into the <Instance>/Pipelines directory.

Using self-registration, all the elements are added to the Process Step by decorating the class with the ProcessStep attribute.

The Deployment section covers both registration methods.

Complex

The Complex model of a custom Process Step provides developers more fine-grain control over the UI properties exposed by custom Process Steps. By referencing the new StepUIElement class, developers can control what icon and label will be displayed when a user drags the custom Process Step onto the Process Design Canvas as well as what appears on in the Process Steps Toolbox. In regards to exposing custom properties to be configured at design time, users can now control the order in which the properties will be displayed, as well as dynamically make properties visible/invisible depending on what the user selects within the property grid.

Similar to the Basic model of Process Step, a Microsoft Visual Studio Class Library Project must be created. However, two .NET Classes must be added. One to represent the custom Process Step Class, the other to represent the UIElement class required by the Design Canvas. Additionally, a Resource File needs to be added for icons and metadata.

A Complex custom Process Step requires the following:

• A Class that inherits from CustomPipelineStep
• A Class that inherits from StepUIElement<MyComplexProcessStep>
• Must include references
  • System.ComponentModel.Composition.dll
  • Neuron.dll
  • Neuron.Esb.dll
  • Neuron.Esb.XmlSerializers.dll
  • Neuron.Pipelines.Design.dll
  • Neuron.UI.dll
  • System.Runtime.Serialization.dll

Using the Complex model, properties can be displayed in a custom defined order and visibility can be dynamically adjusted based on user input

Example

At minimum, a Complex model custom Process step will resemble the following sample:

using System.ComponentModel;
using System.Runtime.Serialization;
using Neuron.Esb;
using Neuron.Esb.Pipelines;
using Neuron.Pipelines;
namespace ComplexProcessStep
{
	[Description("Sample process step with a custom UI")]
	[DisplayName("My Complex Step")]
	public class MyComplexProcessStep : CustomPipelineStep
	{
		/// <summary>
		/// If these properties are required for design time configuration then
		/// they must be replicated in the Wrapper class of the UI Element class
		/// </summary>
		[DataMember]
		public bool IsEnabled { get; set; }
		[DataMember]
		public string ShowMe { get; set; }
		protected override void OnExecute(PipelineContext<ESBMessage> context)
		{
			if (context.Instance.IsInfoEnabled)
				context.Instance.TraceInformation("MyCustomProcessStep called.");
		}
	}
}

In the example above, the attribute, DisplayName attribute (i.e. “My Complex Step”), is used for manual registration deployment to define the name of the Process Step as it will appear in the Process Step Toolbox. The Description attribute (i.e. Sample process step with a custom UI), defines the tool tip that will appear when the mouse hovers over it in the Toolbox. If self-registration is used, the DisplayName and Description attribute are ignored. Generally, only self-registration should be used for Complex model custom Process Steps.

The IsEnabled and ShowMe properties are included as examples to show how to define properties; they are not required. Also notice that the properties for the process step are decorated only with the “DataMember” attribute. This is because the way the properties are displayed is defined in the MyComplexProcessStepUIElement class which means there is no need to define the attributes in the MyComplexProcessStep class.

The sample below shows the StepUIElement class that would accompany the sample class above.

using System.ComponentModel;
using Neuron.Esb;
using Neuron.Pipelines;
using Neuron.Pipelines.Design;
using System.Windows.Forms;
namespace ComplexProcessStep
{
	/// <summary>
	/// This is the UI Element class that determines how the custom Process step will be
	/// represented in both the property grid and Process Designer.
	/// </summary>
	public class MyComplexProcessStepUIElement : StepUIElement<MyComplexProcessStep>
	{
		public MyComplexProcessStepUIElement(Pipeline<ESBMessage> pipeline)
			: base(pipeline, Resource1.MyComplexProcessStep)
		{
		}
		protected override void OnPaint(PaintEventArgs e)
		{
			base.OnPaint(e);
			DrawLabel(e.Graphics, TypedData.Name);
		}
		public override string Label
		{
			get { return "Custom Label"; }
		}
		public override object BindTo
		{
			get
			{
				return new Wrapper(this.TypedData);
			}
		}
		/// <summary>
		/// This exposes the properties bound to the property grid
		/// These properties should map back to the ones in the custom Process
		/// Step class. This is where the Properties Type Converter can be used
		/// to control things like ordering of properties, as well as making
		/// properties dynamically visible/invisible at design time based on
		/// input of user
		/// </summary>
		[TypeConverter(typeof(PropertiesTypeConverter))]
		private class Wrapper : BaseWrapper
		{
			private readonly MyComplexProcessStep step;
			public Wrapper(MyComplexProcessStep step) : base(step)
			{
				this.step = step;
			}
			/// <summary>
			/// This is used to control the visibility of any property based on the
			/// value of the IsEnabled property
			/// </summary>
			/// <param name="attributes"></param>
			public void DynamicShowMeAttributesProvider(PropertyAttributes attributes)
			{
				attributes.IsBrowsable = (IsEnabled == true);
			}
			[PropertyOrder(1)]
			[Category("Default")]
			[DisplayName("IsEnabled")]
			[Description("To test the functionality of PropertyAttributesProvider.")]
			public bool IsEnabled
			{
				get { return this.step.IsEnabled; }
				set { this.step.IsEnabled = value; }
			}
			[Category("Default")]
			[DisplayName("ShowMe")]
			[PropertyOrder(0)]
			[Description("Should be visible only when IsEnabled is set to true.")]
			[PropertyAttributesProvider("DynamicShowMeAttributesProvider")]
			public string ShowMe
			{
				get { return this.step.ShowMe; }
				set { this.step.ShowMe = value; }
			}
		}
	}
}

In the example above, the Resource1.MyComplexProcessStep provides the image displayed on the Design Canvas after the Process Step has been added to it. This is passed to the base constructor of the MyComplexProcessStepUIElement class. The default name of the Process Step as it appears on the Design Canvas is controlled by the Label property.

The Wrapper class, which is decorated with the TypeConverter attribute taking a type of Neuron.Esb.PropertiesTypeConverter, allows the property grid to use the TypeConverter’s functionality. This is accomplished essentially through “wrapping” an instance of the custom process step in a class, which exposes the properties of that custom process step and allows them to be manipulated. The PropertiesTypeConverter type converter provides developers with the PropertyAttributeProvider attribute to control visibility of properties. It also provides the PropertyOrder attribute to control the order in which properties will appear in the Property Page grid.

The following is a description of each of the PropertiesTypeConverter attributes:

• [PropertyOrder(0)]– Used to indicate the order that the property should be displayed in within each category. ‘0’ would put that property at the top of the properties in the property’s category, whereas a higher number will put it lower.
• [PropertyAttributesProvider(“DynamicShowMeAttributesProvider”)]– Used to indicate that there is a method that should be used to control the property’s attributes. In this sample, the following method is used:

public void DynamicShowMeAttributesProvider(PropertyAttributes attributes)
{
	attributes.IsBrowsable = (IsEnabled == true);
}

The PropertyAttributes class contains the attributes for the property that is decorated with the PropertyAttributesProvider attribute (note that the PropertyAttributesProvider attribute uses the method/provider’s name for its parameter). This allows attributes to be dynamically set at runtime. In this sample, the attribute “IsBrowsable” for the ShowMe property is set to whether the IsEnabled process step property is true or false.

The constructor for the Wrapper class uses one parameter which is the custom process step’s class (the base class’s constructor must also be called using the same class as the Wrapper class’s constructor). In this sample, it is the class “MyComplexProcessStep”, as this is the main class for the custom step.

For self-registration, the following ProcessStep attribute is added to the MyComplexProcessStep class:

[ProcessStep(typeof(MyComplexProcessStep), typeof(Resource1), "name",
"description", "ComplexProcessStep_MyComplexProcessStep",
typeof(MyComplexProcessStepUIElement), Path = "Finance Dept/Complex Functions")]

The typeof(MyComplexProcessStepUIElement) argument passed to the ProcessStep attribute directs the Business Process to use the included MyComplexProcessStepUIElement class to control the rendering of the Process Step on the Canvas.

Using the sample code above, once the Microsoft Visual Studio custom Process Step project has been compiled and deployed, the custom Process Step will appear in the Process Step Toolbox and Design Canvas as shown in Figure 57.

Manual registration can be used in exactly the same way as when registering a Basic model Process Step. However, if manual registration is used, the custom StepUIElement class IS IGNORED, which negates the point of using the Complex model for building custom Process Steps. To leverage the benefits of the Complex model, only self-registration can be used.

The Deployment section covers both registration methods.

Deployment

.NET assemblies containing custom Process Steps do not need to be strongly signed.

All custom Process Steps must be copied to the Pipeline folder located under default Neuron installation directory (C:\Program Files\Neudesic euron ESB v3\DEFAULT\Pipelines).

All custom Process Steps must be registered using manual or self-registration.

Manual Registration

Manual registration requires that the custom Process Step class name, assembly name and folder information be entered within the neuronpipelines.config configuration file located in the Pipelines directory. Using the neuronpipelines.config, a stepTypes element must be added for each Custom Process Step registered. The stepTypes element has the following attributes:

Attribute	Description
name	The name of the .NET Class representing the Custom Process Step
value	The full .NET Assembly name
path	The folder path (created under the Process Steps root folder) to display the Custom Process Step. If the folder does not exist, the Process Steps Toolbox will create automatically.

A sample that shows an entry for the Basic Custom Process step example discussed in the previous section would appear as follows:

<neuron.pipelines>
	<stepTypes>
		<add name="MySimpleProcessStep" path="HR Dept/Simple Function" value="SimpleProcessStep, Version=3.0.0.0, Culture=neutral,  PublicKeyToken=null"></add>
	</stepTypes>
</neuron.pipelines>

To use a custom icon, a 16×16 PNG format file along with the .NET assembly must be copied to the Pipelines folder in the Neuron program files installation directory. The name of the PNG must match the fully qualified name of the .NET Class. In the example above, the namespace for the .NET Class is SimpleProcessStep (by coincidence the name of the assembly happens to be the same), while the name of the .NET Class is MySimpleProcessStep. Therefore the PNG file name would be, SimpleProcessStep.MySimpleProcessStep.png

Using the manual registration information above as well as the custom icon file, the Basic Custom Process Step will now appear in the Process Steps Toolbox as shown in Figure 58.

If deploying a Complex model custom Process Step, copying a PNG icon file to the Pipelines folder in the Neuron program files installation directory to use a custom icon will override the use of any icons that it may have compiled in its own resource file. The copied icon will be used for both Toolbox and Design Canvas.

Self-Registration

The neuronpipelines.config configuration is not needed when self-registration is used. Self-registration is accomplished by decorating the .NET Class representing the Process Step with the ProcessStep attribute. All elements needed for registration are embedded in the assembly and declared using the ProcessStep attribute, including which icons to use as shown in the interface definitions below:

Class: ProcessStepAttribute

Namespace:Neuron.Pipelines

Assembly:Neuron.Esb (in Neuron.Esb.dll)

Syntax:

[Serializable]
[AttributeUsage(AttributeTargets.Class)]
[MetadataAttribute]
public class ProcessStepAttribute : ExportAttribute
{
	public ProcessStepAttribute(string processStepTypeName, string name,
		string description, string uiElementTypeName);
	public ProcessStepAttribute(Type processStepType, string name,
		string description, string uiElementTypeName);
	public ProcessStepAttribute(Type processStepType, string name,
		string description, Type uiElementType);
	public ProcessStepAttribute(string processStepTypeName,
		string resourceTypeName,
		string nameResource, string descriptionResource,
		string imageResource, string uiElementTypeName);
	public ProcessStepAttribute(string processStepType, Type resourceType,
		string nameResource, string descriptionResource,
		string imageResource, string uiElementTypeName);
	public ProcessStepAttribute(Type processStepType, Type resourceType,
		string nameResource, string descriptionResource,
		string imageResource, string uiElementTypeName);
	public ProcessStepAttribute(Type processStepType, Type resourceType,
		string nameResource, string descriptionResource,
		string imageResource, Type uiElementType);
	public string Description { get; }
	public string Image { get; }
	public string Name { get; }
	public string Path { get; set; }
	public string ProcessStepTypeName { get; }
	public string ResourceTypeName { get; }
	public string UIElementTypeName { get; }
}

The ProcessStep attribute contains all the information that Neuron ESB Explorer needs to self-register the process step into its Business Process Designer and Process Steps Toolbox. The sample below displays the ProcessStep attribute for self-registration of the Basic Custom Process Step that was discussed earlier in this documentation.

[DisplayName(“My Simple Process Step”)]

[ProcessStep(typeof(MySimpleProcessStep), typeof(Resource1), “name”,

“description”,”Image1″,””, Path = “Finance Dept/HR Functions”)]

public class MySimpleProcessStep : CustomPipelineStep

{

• The first parameter of the attribute is the type of the class of the process step.
• The second parameter is the type of the resource class (*.resx file added to the Microsoft Visual Studio Project) that contains the name, description, and image that the process step uses.
• The third parameter is the name of the string in the resource class that contains the name of the process step. The name in the resource class will be the name displayed in the toolbox of the Process Designer.
• The fourth parameter is the name of the string in the resource class that contains the description that will be displayed when the mouse is hovering over the process step in the toolbox.
• The fifth parameter is the name of the image in the resource file that will be used as the icon for the process step.
• The sixth parameter is a fully qualified type name used to represent the process step in the Process Designer on the design surface. When the Basic Custom Process Step is used, it is an empty string, in which case Neuron will use a default generic UIElement.
• Lastly, the path of where the process step will sit in the Process Designer toolbox can be specified with the Path variable. If it is an empty string, the process step will be located at the root folder “Process Steps” in the toolbox.

Once the .NET Class is decorated with the ProcessStep attribute, the assembly must be compiled and then copied to the Pipelines folder. Nothing else is needed. When the Neuron ESB Explorer is opened, the Custom Process Step should display as shown in Figure 58.

Runtime Deployment

The Custom Process Step .NET assembly, along with any dependencies, must be present in the Pipelines Folder or in the Probing Path defined in the *.config files of the Neuron ESB runtime environments.

If hosting the Neuron ESB Party in a custom .NET application, then the Custom Process Step .NET assembly (along with its dependencies) must be deployed to the bin directory of that application. This is only necessary if the Party references any Business Processes that use the Custom Process Step.