Tracking and persistance services

May 29, 2008 at 11:12 AM
Hi Minas!

We are considering to use ESB.NET in our projects.
Please give us some inputs how to configure, tracking and persistance services in workflows on ESB.NET,
also some notes, links SAP - ESB.NET integration

Thank you,

May 29, 2008 at 2:31 PM
Edited May 29, 2008 at 9:50 PM
Hi Bole,
There are no special requirements in terms of how to configure, tracking and persistance services in workflows on ESB.NET.
It's the same as you otherwise would do with Windows Workflow Foundation, so use the standard MSDN references for WF.

In terms of SAP, last time I did this I used the standard SAP Connector for .NET, in around 2005 or so.
I hit some process specific threading limits at the time, which I circumvented by setting ASP.NET into Web Garden mode (with about 4-6 processes or so). For some reason the SAP Connector was not responding to config changes to change the max threads for their thread pool.

Other than that,
Integration with SAP
- write a standard ESB.NET Service Definition & Service, defining your Input/Output schemas
- use the SAP Connector to call into a SAP BAPI etc.
- map the properties in from the ESB.NET Service into the BAPI generated classes & call BAPI off SAP Proxy, Map output from BAPI to ESB.NET Service Output...

Look at the following:
for inspiration. It's a little old, but should give you an idea of how to get started.

Note that since you're looking at State Based WF Services , you should run them in a separate ESB.NET Instance (ESB.NET Workflow Instance).
This will ensure your scalability issues around managing state & workflows etc. are contained within that instance (or cluster etc.).
Run the SAP Integration services in another instance (ESB.NET EAI Instance). Being stateless, you can scale this out as you wish - Web Farm + Web Garden as required, independently of the State Based WF Instances (ESB.NET Workflow Instance).

If you're big on the WF Orchestration side of things, you can use ESB Orchestrated Services (WF Sequential Workflows) to manage your state transitions. Again, these can run in a separate instance (ESB.NET Services Instance), or being stateless, can be easily included in the ESB.NET Instance hosting the SAP Services.

Note that all the stateless instances (ESB.NET Services Instances, ESB.NET EAI Instances) can be clustered & scaled out via standard Network Load Balancers etc. 

You may want to start off with a single instance, and change config to scale out as you get more comfortable. Deployment changes should all be done using the standard ESB.NET config features.

You can configure the standard ESB.NET RequestHandlerProxy to forward requests across different Service Layers.
In the ESB.NET Database logs, you'll notice the different nodes/Instances processing the various types of requests (Workflow, Services, Integration...).

Business & EA Alignment
In keeping true to the ESB name, in order to get the most out of ESB.NET, once you are comfortable, consider separating functionality into Service Domains, modelled against the High Level Business Services in your organization.
Also, it'd be a good idea to model your service namespaces accordingly, as well as the usual alignment with your Enterprise Information Architecture.

See the Presentation in the Release "OpenStandards Presentation - BPM IMPLEMENTATIONS USING SOA, CIM's AND ESB's" for more info.


May 29, 2008 at 3:33 PM

Thank you very much for your prompt answer.

But I don’t see how I can add tracking and persistence services in workflow run time, inside ESB.NET.  I suppose we should add in some place in config file somting like:

<workflowRuntime name="WorkflowServiceHostRuntime" validateOnCreate="true" enablePerformanceCounters="true">
<add type ="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=3.0.00000.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
connectionString="Data Source=localhost\sqlexpress;Initial Catalog= MyCat; Integrated Security=True;Pooling=False"
LoadIntervalSeconds="1" UnLoadOnIdle= "true" />
 On what place – config file inside ESB.NET  we should add similar one?

 (I figured out how to create workflow and place it in the C:\Data\Projects\ESB\Deploy\6\\Source\ESB\LobSystems\ns directory and access one over client like service.)


Thank you,


May 29, 2008 at 9:53 PM
Edited May 30, 2008 at 9:22 PM

Yep, that configuration sits in the following 2 places:


i.e. once for each of the 2 Virtual Directories ESB.NET uses to host your services.
You'll find there's already some Workflow Runtime config in there.

Also, Workflow support is not embedded into the ESB.NET core. It is via Adaptors. As such, you can change it all you like, whenever you like, and only deploy whichever functionality is required with each ESB.NET instance.
For example, you don't need the State Based/Tracking type config for Services and Integration instances, just for the State Based Workflow specific ESB.NET Instances.

The Adaptors sit here:


and are invoked via configuration.


May 30, 2008 at 7:09 AM

Thank you, more once for prompt and valuable answers.



Jun 5, 2008 at 11:56 AM

Out of interest, I just came across this ancient post re: SAP connector problems...
It was with VS.NE 2003 and .NET 1.1... (in 2005)...