One of the very new cool features in Neuron ESB is the ability for users to create their own custom pipeline steps, and have those steps show up in the right hand Pipeline Step pane within the Neuron ESB Pipeline Designer. This provides a great way for developers to create reusable code assets for other developers to use with any project.
Previously, if a developer wanted to create new capabilities using Visual Studio and reuse those capabilities within Neuron, it required creating a library assembly and referencing that assembly within a Code Pipeline Step. If there were N number of Code Pipeline Steps, the assembly would have to be re referenced in each one. Obviously, if the assembly changed, all Code Pipeline Steps would have to be changed as well.
Custom Pipeline Steps allow developers to create reusable capability that doesn’t require re referencing custom assemblies within Code Pipeline Steps. Furthermore, new capabilities can be parameterized and driven by publicly exposed properties using the Neuron property grid (lower right hand corner of the designer), controlling exactly how developers interact with the new capability both at design time and runtime.
Using Custom Pipeline Steps is a three step process, Create, Deploy and Register:
· Create the Custom Pipeline Step
· Deploy the Custom Pipeline Step into the Neuron Pipeline sub directory
· Register the Custom Pipeline Step within the neuronpipelines.config configuration file
Creating a Custom Pipeline Step
Creating a Custom Pipeline Step requires creating a Visual Studio .NET C# Class project. This will have at least 1 class that implements the Neuron.Esb.Pipelines.CustomPipelineStep base class. This base class has one method to override, OnExecute().
This class can optionally contain public properties that are exposed using the Microsoft Property Grid within the Neuron ESB Pipeline Designer. The class attributes, DisplayName and Description are used to control what name and description are displayed within the Neuron ESB Pipeline Designer.
Additionally, a graphic (PNG 16x16) can be included in the project. This graphic is used as the icon that represents the Custom Pipeline Step within the Neuron ESB Pipeline Designer window. The file name of the graphic must exactly follow that of the namespace and class name of the Custom Pipeline Step class.
For example, if the namespace of the Custom Pipeline Step is “Neuron.Pipelines.CustomSamples” and the class name is “MyCustomPipelineStep”, then the image file included in the Visual Studio .NET C# Class library must be named, “Neuron.Pipelines.CustomSamples.MyCustomPipelineStep.png”
Once the Custom Pipeline Step is compiled, it is ready to deploy.
A sample of a Custom Pipeline Step can be found in the Samples\Features\Pipelines\Neuron.Pipelines.CustomSamples directory located at the root of the Neuron ESB installation directory
NOTE: Custom Pipeline Steps can optionally be signed with a strong named key (snk) if they need to be copied to the Global Assembly Cache (GAC).
Deploying a Custom Pipeline Step
Deploying a Custom Pipeline Step involves copying the previously created assembly that contains it, to the Pipelines directory located at the root of the Neuron ESB installation directory.
If using the Neuron ESB Client API on a remote machine that is NOT running the Neuron ESB Service (hosted by a custom application), than that assembly should either be deployed to the local GAC, or in the Bin directory of the hosting application.
Registering a Custom Pipeline Step
Once a Custom Pipeline Step is deployed, it must be registered in the neuronpipelines.config file within the Pipelines directory located at the root of the Neuron ESB installation directory:
<neuron.pipelines>
<stepTypes>
</stepTypes>
</neuron.pipelines>
Registration requires inserting the assembly reference by using the “Add” element as follows:
<neuron.pipelines>
<stepTypes>
<add name="MyCustomPipelineStep" value="Neuron.Pipelines.CustomSamples, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ecaf0c45d7be0e34"/>
</stepTypes>
</neuron.pipelines>
Once the registration is complete, the Neuron ESB Service must be restarted if using Service Endpoints or Adapter Endpoints that will be using the Custom Pipeline Step.
If using the Neuron ESB Client API on a remote machine that is NOT running the Neuron ESB Service (hosted by a custom application), than the new Pipeline Step’s registration information needs to be added within the App.Config file of the hosting application as follows:
<configuration>
<configSections>
<section name="neuron.pipelines" type="Neuron.Configuration.PipelinesConfigurationSection, Neuron"/>
</configSections>
<neuron.pipelines>
<stepTypes>
<add name="MyCustomPipelineStep" value="Neuron.Pipelines.CustomSamples, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ecaf0c45d7be0e34"/>
</stepTypes>
</neuron.pipelines>
</configuration>
Thanks to all that attended the integration roadshow today! As promised, here is the deck I presented for the last session around Building Hybrid Composite Services Using AppFabric and BizTalk Server 2010. The roadshow started exploring the integration platform and many of the new aspects of Windows Server AppFabric and Windows Azure AppFabric. BizTalk is still a critical part of the integration platform. If you are only using BizTalk though, you are missing out on some great new aspects of the Microsoft platform to build out your solutions. The roadshow is still touring the US so make sure to attend if you still can!
Microsoft Business Integration Roadshow Calendar
Building Composite Enterprise Hybrid Services with BizTalk 2010 and AppFabric Simple.pdf (2.97 mb)
From time to time I would get into problems with persisted workflows, e.g. I could not resume it nor terminate it due to the system being unable to de-serialize workflows. If we change a workflow or any type that is serialized with it – there could be, actually there will be problems with long running and persisted workflows for sure.
WF 4.0 is much easier in this respect, since the new persistence provider serializes only the activities containing active bookmarks and the objects in the current scope. In many cases versioning effort can be limited by focusing on the fields added to the custom types, where .NET serialization attributes, such as [System.Runtime.Serialization.OptionalField] can be of great help.
In my last post, I introduced you to the Managed Extensibility Framework for creating composable applications made out of parts. In this post, I’m going to start exploring the new Workflow Foundation technology that was re-introduced with .NET 4.0. Over the next few days, I’ll explore different aspects of Workflow Foundation and look at how it can be used to create customizable and extensible applications. But in this post, we’re going to start with the basics: hosting the workflow designer. More...