1. WF APPLICATION IN RETAIL
BANKING ENTERPRISE
SYSTEMS
Key challenges in developing long running &
dynamically evolving worfklows
2. Goals
■ Provide a real life example of an enterprise system that utilizes WF
■ Demonstrate key benefits of using WF
■ Outline some of the challenges that accompany WF applications
■ Acess design options for combining a workflow framework with DDD
3. Disclaimer
■ System used an example is a legacy system built in .NET 3.5, that was in
production for over 5 years
■ System does not demonstrate new features of WF 4.5, and best practices of
architecture and design
■ Presenter does not claim to be an expert in WF
4. Introduction
Definition from investopedia:
■ Retail banking is when a bank executes transactions directly with consumers,
rather than corporations or other banks.
■ Services offered include savings and transactional accounts, mortgages,
personal loans, debit cards, and credit cards.
■ The term is generally used to distinguish these banking services from
investment banking, commercial banking or wholesale banking.
■ It may also be used to refer to a division of a bank dealing with retail customers
and can also be termed as Personal Banking services.
5. Why retail banking?
Process of a retail loan issuing is a great use case for WF, due to the following
characteristics
■ long-running
■ non-linear
■ numerous states/stages
■ distributed between participants
■ numerous branching & complex business logic
■ dynamically evolving (changes frequently)
■ requires support of multiple versions
6. Side notes
Credit scorecards and recognizing revenue ;-)))
■ A software system can be flexible enough to incorporate changes in the
business process fast enough, but is accounting and risk just as flexible to be
able to make a financial projection of the changes applied to the business
process?
■ Stories from the trenches of local UA banking reality
7. High-level requirements
■ Secure in the business sense = fraud resistant (not always used from secure locations, sometimes
employees consciously contributing to a fraud with a client)
■ Scalable (amount of retail points will grow over time, work load is distributed non-uniformly across
working hours)
■ Reliable (targeted at 98.5% availability - a bug in a system will kill the ability to issue loans, i.e. to do
main business, and this will adversely affect sales and income). As in most areas, customer activity
is not uniform across the day / week, and a loss of 1.5% uptime can cause a loss of 10% income
■ Maintainable (relatively small changes and extensions in the business process should not take a lot
of time to implement & need to be able to roll out changes fast)
■ Versionable - need to be able to run current and previous version of the workflow side by side
■ Comprehendable - business process model has to be understandable by business (ubiquitous and
unambiguous) and easy to communicate
■ Traceable (need to explain exactly what happened with a specific instance of business process) -
these are most frequent support queries
8. Domain and business process
peculiarities
■ Business process includes human interaction - such as manual multi-step verification of data by call
centre, i.e. directly calling the numbers provided by the client
■ Business process includes interactions with external systems which may considerably modify the
workflow of a specific work item (risk & scoring engine)
■ Results of both human and system interactions can be checked once again by a credit expert
■ Business transactions are long - running, they can last from a couple of hours to several weeks
■ Business process is non-linear, i.e. apart from branches it can have "loops" - i.e. return to previous
stages (better modelled as a state machine)
■ Amount of transactions is reasonably small < 100 000 per day, top load < 10 operations per second
■ Amount of data is relatively small = 10-50 mb of document scans per business transaction
■ Some of the steps in the process are relatively computationally heavy (such as parsing scanned
documents to find a bar-code)
9. Why use WF?
Some of the benefits OOB
■ Declarative programming model
■ Traceability
■ Runtime flexibility
■ Versioning & side-by-side
execution
■ Dynamic update
■ Flow management
■ Composability
■ Persistance
■ Scalability
■ Messaging
■ Reliability via Cancellation,
Compensation and Transactions
■ Visibility, transparency and
readability
10. Declarative programming model
■ While WF falls short to be a "sort of" DSL, but does enable declarative
programming and code reuse by allowing to create custom activities that will
allow to model and express problem at hand in the language of the problem
domain.
■ WF promotes component-based architecture style, which generally results into
more reusable, replaceable, low coupled, context-independent, and extensible
code.
■ Microsoft reuses code with WF at a greater scale by using this engine in CRM,
BizTalk and SharePoint
12. Traceability with tracking services
■ Windows Workflow tracking is a .NET Framework 4.5 feature designed to
provide visibility into workflow execution. It provides a tracking infrastructure to
track the execution of a workflow instance. The WF tracking infrastructure
transparently instruments a workflow to emit records reflecting key events
during the execution. In general, enabling WF tracking facilitates diagnostics or
business analytics data to be accessed from a workflow execution.
■ These tracking components are equivalent to the tracking service in .NET
Framework 3.0. In .NET Framework 4.5, the performance has been improved and
the programming model simplified for the WF tracking feature. The tracking
runtime instruments a workflow instance to emit events related to the workflow
life cycle, workflow activities and custom events.
13. Traceability with tracking services
Primary components of the tracking infrastructure are
■ TrackingRecord objects emitted from the workflow runtime.
■ TrackingParticipant objects subscribe to TrackingRecord objects. The tracking
participants contain the logic to process the payload from the TrackingRecord
objects.
■ TrackingProfile objects filter tracking records emitted from a workflow instance.
14. Traceability with tracking services
■ The workflow tracking infrastructure follows a publish-and-subscribe paradigm. The
workflow instance is the publisher of tracking records, while subscribers of the
tracking records are registered as extensions to the workflow. These extensions that
subscribe to TrackingRecord objects are called tracking participants. Tracking
participants are extensibility points that access TrackingRecord objects and process
them in whatever manner they are written to do so. The tracking infrastructure
allows the application of a filter on the outgoing tracking records to allow a
participant to subscribe to a subset of the records. This filtering mechanism is
accomplished through a tracking profile file.
■ Tracking profiles are used to specify which tracking information is emitted for a
workflow instance. If no profile is specified, then all tracking events are emitted. If a
profile is specified, then the tracking events specified in the profile will be emitted.
Depending on your monitoring requirements, you may write a profile that is very
general, which subscribes to a small set of high-level state changes on a workflow.
Conversely, you may create a very detailed profile whose resulting events are rich
enough to reconstruct a detailed execution flow later.
15. Visibility, transparency and readability
■ Visual modelling
■ Visual tracking by consuming workflow tracking records and (optionally) re-
hosting workflow designer
■ Visual debugging
16.
17. Runtime flexibility
Workflows can be represented as xaml, which, obviously enables a number of
benefits:
■ Easy persistence
■ Ability to be loaded and executed at runtime
■ Difference between workflows can be computed using xml compare tools, xpath
expressions etc. or using new WorkflowInspectionServices
■ Workflows can be dynamically built, adjusted and composed at runtime based
on rules / business logic
18. Composability
■ A workflow is an Activity, so workflows can be easily nested
■ StateMachine is a NativeActivity, that derives from Activity
■ Flowchart is a NativeActivity
■ In summary, all three types of workflows Sequential, StateMachine and
FlowChart can be composed into arbitrary complex structures
19. Versioning & side-by-side execution
■ Based on WorkflowIdentity {name;version} (exposed as DefinitionIdentity
property of workflow)
■ Side by side execution allows to support execution of several versions of
workflow simultaneously
■ Dynamic update allows to set a transformation of existing instance of a workflow
20. Dynamic update
Dynamic update provides a mechanism for workflow application developers to update
the workflow definition of a persisted workflow instance
■ Prepare the workflow definition for update
(System.Activities.DynamicUpdate.DynamicUpdateServices.PrepareForUpdate)
■ Update the workflow definition to reflect the desired changes (You can add or
remove activities, add, move or delete public variables, add or remove arguments,
and make changes to the signature of activity delegates via code or re-hosted
designer)
■ Create the update map
(System.Activities.DynamicUpdate.DynamicUpdateServices.CreateUpdateMap)
■ Apply the update map to the desired persisted workflow instances
(System.Activities.WorkflowApplication.Load that takes a DynamicUpdateMap and
then Unload)
21. Persistance
■ Persistance in WF since .NET 4.0 is implemented via SqlWorkflowInstanceStore
: InstanceStore that only supports persistance to SQL Server 2005 and 2008
■ Persistence enables process agility, scalability, recovery in the face of failure,
and the ability to manage memory more efficiently.
■ The persistence process includes the identification of a persistence point, the
gathering of the data to be saved, and finally the delegation of the actual storage
of the data to a persistence provider.
■ To enable persistence associate an instance store with a WorkflowApplication
by using the InstanceStore property of the WorkflowApplication class
22. Reliability via Cancellation,
Compensation and Transactions
■ Transactions give your application the ability to roll back all changes executed within
the transaction if any errors occur during any part of the transaction process.
■ However, not all work that may need to be canceled or undone is appropriate for
transactions, such as long-running work or work that does not involve transactional
resources.
■ Compensation provides a model for undoing previously completed non-transactional
work if there is a subsequent failure in the workflow.
■ Cancellation provides a model for workflow and activity authors to handle non-
transactional work that was not completed.
■ If an activity has not completed its execution and it is canceled, its cancellation logic
will be invoked if it is available.
23. Host to workflow engine interaction
■ WorkflowInvoker, when it is enough to invoke the workflow by calling a method
( a simple way for invoking a workflow as if it were a method call and can be
used only for workflows that do not use persistence)
■ WorkflowApplication for explicit control over the execution of a single workflow
instance, extensive api is offered by this class, such as life - time event
callbacks (provides a richer model for executing workflows that includes
notification of lifecycle events, execution control, bookmark resumption, and
persistence)
■ WorkflowServiceHost for message-based interactions in multi-instance
scenarios, mostly for workflow services (provides support for messaging
activities and is primarily used with workflow services)
24. Challenges: Long running business
workflows and evolving system
■ Persistence of domain objects that change frequently. Persistence options:
immutable snapshot of whole data vs identities only. Binary or text.
■ Although data flow between activities is organized using activity Arguments and
Variables, in combination with Binding - we still need to communicate with
domain.
■ Consider that supporting changes to domain model were made. How do we
isolate these changes - make a branch, build a separate "variant" sub-branch of
code tree
■ Deploy, host and execute in a separate app domain and have domains interact
between themselves based on version numbers
■ As an alternative, have two copies of the whole environment deployed. Keep in
mind other integrated software systems inside the bank.
25. Sources used
■ MSDN
■ Pro WF 4.5, Apress
■ Teach Yourself Workflow Foundation in 24 hours, Sams
