May 29, 2008 at 2:31 PM
Edited May 29, 2008 at 9:50 PM
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
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.