SimpleWorkflow in the CloudPOA June 17, 2010Alan Robbins and Rick Sears

Todays TalkMotivations and GoalsAWS SimpleWorkflow (SWF)Building WorkflowsWorkflow Patterns

Synchronous Web Services

A Workflow We All Know About

Can you recognize a Workflow?Most developers dont know of workflowsIm just building my application!This is simple, I just need a couple of states100s of workflows at Amazon right now!Indicators?Tasks longer than ~5 secondsSweep a database looking for stateSequence of tasks connected by queuesPolling for activity completionDistribute tasks to daemonsBackground or batch jobs

What is a Workflow?Multi-step activity orchestrationBusiness logic relating those activitiesAddress failures and exceptionsMay be long-lived business activitiesAsynchronous or event-driven executionLasting minutes or months (or longer) Involve human decision makingSpan organizational boundaries

BPM Market Segment

BPM Market SegmentRecognized ubiquitous needMany standard workflow modeling languagesBPML, WSFL, WSCL, BPSS, XLANG, WSCI, WS-CDL, XAML, jPDL, xPDL, BPEL, YAWL, Many Sophisticated BPM Software ProductsIBM, Tibco, Oracle, Microsoft, JBoss, ...Most extend a standard or require a proprietary workflow modeling languageVast majority of developers still build ad hocHuge market opportunity!

BPM Product ArchitectureXML-based Workflow DefinitionBPM Workflow EngineDatabase

Downside of BPM ProductsLarge up-front costs (besides the $ for product)Require users to host the engine and databaseStart with an esoteric XML modeling languageSteep learning curve barrier for developersDevelop within a proprietary frameworkExpose external functionality as SOAP endpointsAdd-on ESB technology and build adaptors Approach is neither flexible nor scalable Not designed for the cloud

Workflows in the Cloud?

Unique Musts of Cloud ServicesService, not software product!Low barrier to entryWide appealSuitable for mission critical appsSupport any programming language Inexpensive relative to software productsNo practical scalability limitationsSecure

SimpleWorkflow Design GoalsOpen Architecture for DevelopersLow-level Primitives with a Simple APIProvide all the Runtime InfrastructureEnable users to define workflow capabilities that are:CompositionalCustomizableSharableMonetizable

Marketplace of Cloud Capability

Anyone can offer their activities and workflowsDocument API and extension pointsInclude pricing plansBUY enables accessSimpleWorkflow brokers all interactionsAuthentication, permissions, metering & billingAmazon to offer capabilitiesUtilizing other AWS services (S3, EMR, MTurk, )Amazons eCommerce capabilitiesMarketplace of Cloud Capability

How to Accomplish these Goals?

We had an Insight!

We had an Insight!For any workflowRegardless of representation languageRegardless of simplicity or complexityEven in exceptional situations At any point in time the decisions about what to do next can be coded as a stateless function of what happened before!

A Decider Represents a Workflow Dont need to define a modeling language!Decider(stateless function)WorkflowHistory

Events Inputs ResultDecisions

SimpleWorkflow isnt

SimpleWorkflow ArchitectureSimpleWorkflow

Activity WorkersExternal worker processesDeployed on multiple hostsReceive Activity Tasks [Input]Respond Completed [Result] or Failed

while true {Poll for Activity Task (long poll)Respond Completed (with Result) or Failed}

Activity WorkersExternal worker processesDeployed on multiple hostsReceive Activity Tasks [Input]Respond Completed [Result] or Failed

while true {Poll for Activity Task (long poll)} Respond Completed (with Result) or Failed

DeciderExternal worker processesDeployed on multiple hostsReceive Workflow Tasks [History]Respond Completed [Decisions] or Failed

while true {Poll for Workflow Task (long poll)Respond Completed (with Decisions) or Failed}

Decider is OpenMany innovative implementation approaches:Decider Framework [available now]Annotations FrameworkxPDL InterpreterAsynchrony?

Worker ProtocolsAdvantages of pollingSecure: no endpoint exposed to the Internet!Workers can be located behind corporate firewallsAutomatic throttling and load balancingEasier to implement for many app typesDownsides of pollingA lot of work for nothingTo reduce latency, clients aggressively pollLong polling: from Jabber and CometEliminates the downsides of pollingPush protocols will be supported soonSOAP and REST web services (+ BSF for Amazon internal)SNS task delivery

Runtime Infrastructure

Runtime InfrastructureWF State PersistenceTask SynchronizationScheduling & QueuingTimeout ManagementTask Routing Versioning

Access/PermissionsMonitoring/MetricsMetering and BillingAudit TrailArchivalConsole

Simple APIWorkflow InstancesStartSignalTryCancelTerminate

Visibility of InstancesList, Describe, GetHistory

Access/PermissionsGet/SetPolicy, Associate

Activity & Decider TasksPollForTaskRespondCompleted or Failed

DecisionsSchedule ActivityTryCancel ActivityRecord Split/JoinComplete SignalComplete Workflow

TakeawaysWorkflows are multi-step asynchronous capabilities which may be very long livedWorkflows are ubiquitous You probably have them if you know it or not!Requires special techniques and infrastructureSimpleWorkflow is a cloud-centric AWS serviceProviding all the infrastructure you needMarketplace enables sharing and monetization

Building Workflows using SWF

Two ApproachesChoreographyOrchestration

ChoreographiesParticipants coordinate actions between one anotherEveryone must know:Where to look?Whom to tell?How to handle the unexpected?How to report status?Item Processing Pipeline

OrchestrationsActions coordinated by centralized decision makerWorkers only need to know:How to do their jobHow to communicateCentralized status and failure handlingApollo deployment

SWFs RoleBoth are valid approachesRecognized need for support for orchestration approachSWF acts as auditable coordinator between:Decider acting as orchestratorActivity workers performing specific jobs

Getting Started

First Things FirstBreak your workflow into piecesWhat activities?What data do they need?How do they relate to one another?What do I do when things go wrong?How do I know whats happening?Understand how the workflow will evolve

Next Steps

Tell us about those pieces

Connect Activity WorkersSimpleWorkflow

Connect DeciderSimpleWorkflow

Kick it off!

Designing Complex Systems

Design PatternsFamous GOF patterns for designing softwareCovers common practices in a language agnostic wayBuilding blocks of application logicSome examples:CreationalSingleton, Factory MethodStructuralFaadeBehavioralVisitor

Workflow PatternsCommon practices for building multi-step applicationsBuilding blocks for orchestrating applicationsSome examples:ControlSequence, Parallel Split, Synchronization, DataData-based Routing, Scope Data, Exception HandlingDeadline Expiry, ResourceRetain Familiar,

More InformationPatterns collected and documented by a team lead by Professor Wil Van Der Aalst and a team lead by Professor Arthur ter Hofstede.More details at:

www.workflowpatterns.com

Patterns and SWF

Control PatternsSequenceStructured LoopExclusive Choice with Simple MergeParallel Split with SynchronizationPersistent Trigger

Sequence

SequenceSimplest of all patternsUsed with other patterns to form complex workflowsAlso cover Task Data patternSWF primitives supporting this pattern:Scheduling of activities with dataHistory of events

WorkflowInstanceStartedWorkflowTaskScheduledHistorySimpleWorkflowStartWorkflowInstance

WorkflowInstanceStartedWorkflowTaskScheduledHistorySimpleWorkflowPollForWorkflowTaskResponse

SimpleWorkflowRespondWorkflowTaskCompletedSchedule A1DecisionsWorkflowTaskCompletedActivityTaskScheduled A1History

SimpleWorkflowPollForActivityTaskResponseActivityTaskScheduled A1ActivityTaskStarted A1HistoryInput_1 = FOOActivity Task

SimpleWorkflowRespondActivityTaskCompletedDatum_1 = FOOResultActivityTaskStarted A1ActivityTaskCompleted A1WorkflowTaskScheduledHistory

Structured Loop

Structured LoopDeals with bounded re-executions of steps or collections of stepsSimple example entails retries of single stepAlso cover Deadline Expiry exception handling patternSWF features supporting these patterns:Activity timeoutsRescheduling activitiesn

SimpleWorkflowPollForActivityTaskResponseActivityTaskScheduled A2ActivityTaskStarted A2History

SimpleWorkflowRespondActivityTaskCompleted

HistorySimpleWorkflowPollForWorkflowTaskResponseActivityTaskStarted A2ActivityTaskTimedOut A2WorkflowTaskScheduled

SimpleWorkflowRespondWorkflowTaskCompletedSchedule A2 (2)DecisionsActivityTaskStarted A2ActivityTaskTimedOut A2ActivityTaskScheduled A2History

SimpleWorkflowPollForActivityTaskResponseActivityTaskStarted A2ActivityTaskTimedOut A2ActivityTaskScheduled A2ActivityTaskStarted A2History

SimpleWorkflowRespondActivityTaskCompletedDatum_1 = FOOResultActivityTaskStarted A2ActivityTaskCompleted A2WorkflowTaskScheduledHistory

ActivityTaskStarted A2ActivityTaskTimedOut A2ActivityTaskScheduled A2ActivityTaskStarted A2ActivityTaskCompleted A2WorkflowTaskScheduledHistorySchedule A3Decisions

Exclusive Choice with Simple Merge

Exclusive Choice with Simple MergeChoose one step (or set of steps) over anotherChoice can be based on results of activity executionAlternative path merged back with normal control flow at later pointSimple example entails handling of a failure conditionAlso cover Data-based Routing patternSWF features supporting these patterns:Explicit failure notificationData passing and persistenceab

SimpleWorkflowPollForActivityTaskResponseActivityTaskScheduled A2ActivityTaskStarted A2History

SimpleWorkflowRespondActivityTaskFailedFAULT_DETAILS = FOOResultActivityTaskStarted A2ActivityTaskFailed A2WorkflowTaskScheduledHistory

HistorySimpleWorkflowPollForWorkflowTaskResponseActivityTaskStarted A2ActivityTaskFailed A2WorkflowTaskScheduled

SimpleWorkflowRespondWorkflowTaskCompletedSchedule A4DecisionsActivityTaskStarted A2ActivityTaskFailed A2ActivityTaskScheduled A4History

Parallel Split with Synchronization

Parallel Split with SynchronizationExecute two or more steps (or sequences of steps) at onceContinue forward with only one branch once parallel activities are doneAlso cover Scoped DataSWF features supporting these patterns:Recording split/joinScheduling with split/joinBranch-scoped data

WorkflowInstanceStartedWorkflowTaskScheduledHistorySimpleWorkflowPollForWorkflowTaskResponse

SimpleWorkflowRespondWorkflowTaskCompletedRecord SplitSchedule A1Schedule A2DecisionsWorkflowTaskCompletedSplitRecordedActivityTaskScheduled A1ActivityTaskScheduled A2History

SimpleWorkflowPollForActivityTaskResponseSplitRecordedActivityTaskScheduled A1ActivityTaskScheduled A2ActivityTaskStarted A1History

SimpleWorkflowPollForActivityTaskResponseActivityTaskScheduled A1ActivityTaskScheduled A2ActivityTaskStarted A1ActivityTaskStarted A2History

SimpleWorkflowRespondActivityTaskCompletedDatum_1 = FOOResultActivityTaskStarted A1ActivityTaskCompleted A1WorkflowTaskScheduledHistory

SimpleWorkflowPollForWorkflowTaskResponseActivityTaskScheduled A1ActivityTaskScheduled A2ActivityTaskStarted A1ActivityTaskStarted A2ActivityTaskCompleted A1WorkflowTaskScheduledHistory

SimpleWorkflowRespondWorkflowTaskCompletedDecisionsActivityTaskStarted A1ActivityTaskStarted A2ActivityTaskCompleted A1WorkflowTaskScheduledWorkflowTaskStartedWorkflowTaskCompletedHistory

SimpleWorkflowRespondActivityTaskCompletedDatum_1 = BARResultActivityTaskStarted A2ActivityTaskCompleted A2WorkflowTaskScheduledHistory

SimpleWorkflowPollForWorkflowTaskResponseActivityTaskCompleted A1ActivityTaskCompleted A2WorkflowTaskScheduledHistory

SimpleWorkflowRespondWorkflowTaskCompletedRecord JoinSchedule A3DecisionsActivityTaskCompleted A1ActivityTaskCompleted A2WorkflowTaskCompletedJoinRecordedActivityTaskScheduled A3History

Persistent Trigger

Persistent TriggerTrigger from external process affecting the workflow executionTriggers come in the form of signalsWorkflow can wait for a period of time for signalAlso cover Event-based Task TriggerSWF features supporting these patterns:Signal workflowComplete signalSchedule activity with delayCancel activity

ActivityTaskStarted A1ActivityTaskCompleted A1WorkflowTaskScheduledHistorySimpleWorkflowPollForWorkflowTaskResponse

SimpleWorkflowRespondWorkflowTaskCompletedSchedule Wait (Empty, Delayed)DecisionsWorkflowTaskCompletedActivityTaskScheduled WaitHistory

ActivityTaskScheduled WaitSignalRecordedWorkflowTaskScheduledHistorySimpleWorkflowSignalWorkflowInstance

SimpleWorkflowPollForWorkflowTaskResponseActivityTaskScheduled WaitSignalRecordedWorkflowTaskScheduledHistory

SimpleWorkflowRespondWorkflowTaskCompletedComplete SignalCancel WaitSchedule A2DecisionsWorkflowTaskCompletedSignalClosedActivityTaskCancelTried WaitActivityTaskCanceled WaitActivityTaskScheduled A2History

ActivityTaskStarted WaitActivityTaskCompleted WaitWorkflowTaskScheduledHistory?Decisions

Many moreMulti-ChoiceCancelling DiscriminatorBlocking Partial JoinMultiple Instances with a Priori Run-Time KnowledgeInterleaved Parallel RoutingCancel RegionExplicit TerminationDirect DistributionCapability-Based DistributionSelection AutonomySuspension-Resumption Workflow DataData Interaction - to Multiple Instance TaskTask Postcondition - Data Existence

Decider FrameworkProvides direct support for many patternsBuild workflows by composing scoped decidersSimple set of components combine to express complex workflows

Composing Deciders

Provided Decider ImplementationsWorkflowDecider closes/fails workflow and input/resultActivityDecider controls single activity execution and retriesSequenceDecider sequence of decidersSwitchDecider one of the set based on conditionSplitJoinDecider parallel execution of decidersWhileDecider loop with preconditionDoWhileDecider loop with postconditionTryCatchFinallyDecider exception based error handlingWaitForSignalDecider blocks execution until signal receivedDelayDecider delays execution of a deciderRetryDecider retries execution of a decider in case of failuresConditionDecider conditionally executes a decider

LinksPatterns:www.workflowpatterns.comWiki:w.amazon.com/?SWFEmail:swf-core@amazon.comswf-users@amazon.comswf-announce@amazon.comContact-us

TakeawaysSteps to build and execute workflows using SimpleWorkflowWorkflow patterns are useful conceptual design toolsSimpleWorkflow has the capabilities necessary to express many workflow patternsFrameworks are available to make your job easier

Thanks!SWF TeamRodrigo De CastroDrew GochenaurMaxim FateevJacques ThomasAndy KotlinskiFatih BoyaciPat MaguireSrikanth SatyanarayanaPOA Talk AdvisorsUsers

Not going into internals todayPlease hold your questions to the endwe have a lot to cover and so little time!*Are amazing!Gurupa call graph using Cartographer a year agoBut theres an lot of other things going on under the surface *Fulfillment we know about!*I will betIndicators*BPM Business Process Management is a fancy word for workflow

* Market opportunity!**All follow the same basic architectureStart with an XML modeling languagePossibly created using a graphical builderBesides that (is a black box)

*So what do we really need in the cloud?*Secure in many dimensions (access, data, )Beyond that required for enterprise products.*Cross organization boundaries!!*REMOVE SLIDE

First let me tell you what Im not going to do.

Im not going to show off a fancy GUI modeling environment, drag around some blocks and arrows, and proclaim weve built a enterprise-level workflow.

This is not the starting point for discussing SimpleWorkflow.

We need to look at what underpins these GUI modeling environments to understand how workflows actually run.*DF: Rick will talk aboutPaul FranklinMaxim FateevPatrickMaguire (intern)*WF State is HistoryOnce only delivery and serial decisionsTimeouts insure workflows progress in the face of failuresDirecting tasks to groups of workers or individual workers

*In this next part well look at how you use the SimpleWorkflow service to build and execute workflows.*There are two main approaches to coordinating participants in a multi-step distributed application: choreographies and orchestrations.

Sometimes they work separately, often they work together within an overall process.*Participants in a choreography coordinate actions between one another.

In the real world, ballets

Applications usually coordinate through some sort of shared resource like a message queue.

Choreographies involve agreements between participants about shared signals that indicate when a participant should perform a certain action.

This signal could be a message in a queue, or a network broadcast, or even a specific time.

Every participant in the choreography needs a full understanding of where to look for these signals to know when to execute a task.

They all need to know how to inform others about the completion of a task to trigger the execution of the next task.

But unexpected problems can occur, such as missing participants, duplicate signals, or bad data, and there are issues with how these problems are handled independently by each participant.

It is also not always clear where one should look for an up-to-date status of the overall process execution.

Many examples within Amazon, but one example of this approach might be a subset of the item processing pipeline*Orchestrations differ from choreographies by having all coordinations between participants happening through a centralized entity or entities.

Since the logic about what should happen when is contained in this centralized entity, the participants really only need to know:

the logic to execute their specific task,

how to receive indications that their task should execute,

and how to report back to the central orchestrator their status.

Handling unexpected events rests for the most part in the centralized orchestrator. Overall status can be made available by this centralized orchestrator as well.

Flexible handling of changes to overall process through changes in centralized logic.

As with choreographies, there are many examples of orchestrated multi-step applications within Amazon. An example of this approach is the Apollo deployment system*Both choreographies and orchestrations are valid approaches, and like I mentioned before both these approaches are used all over the place within Amazon.

There are tradeoffs in complexity with both approaches, one having more complexity in the workers while another having complexity in the centralized conductor.

But we do feel that the orchestration approach better supports cross-team and cross-organization use cases due to its relaxation of requirements on workers.

But while there are good infrastructure systems to support choreographies, like the use of AMP or SQS to connect coordinated workers, we felt there are not the right level of supports for orchestrated applications.

So, as Alan discussed in the beginning of this talk, SWF was built to provide infrastructure supports to orchestrated applications.

The role SWF takes is that of a centralized auditable coordinator between the Decider that acts as the conductor for the orchestration and the workers performing their specific jobs.*Ok, so you have an multi-step application that youve identified as needing orchestration supports.

Lets quickly go over what you need to do to get started using SWF.*First things first, you need to take your orchestrated multi-step application, or workflow, and break it apart into conceptual pieces.

You need to figure out what activities are part of the workflow you want to run using SWF.

You should understand what information they need to get a job done.

At a higher level, you need to be able to express how each activities relates to one another in the overall process you are trying to execute.

And you definitely need to think about what you are going to do when things go wrong.

Since you are going to operate these applications in production, you need to figure out how to know whats happening at any given time.

Now that youve broken your workflow down into all its parts, connections, and behaviors, you need to understand how you are going to evolve the implementation over time. It will happen, and you need to make sure things are built for seemless change.*Once youve finished the conceptual modeling of your workflow, you can start the next steps to getting a workflow running using SWF.*You can start using SWF by first telling us about the pieces you are using to execute your workflow.

This happens by registering both the workflows and activities with the service using either service methods or a web-based console.

Why registration?

SWF does not take in a complete workflow definition and then setup all the pieces for you.

Were just the coordinator and auditor, not the conductor.

Youll need to tell us about the workflow you want to execute and also tell us about each activity which that workflow will use during its execution.

The activities are not directly bound to a specific workflow so that they can be used over and over again in many different workflows.

Benefits:

Default behaviorsPer-activity and per-workflow metricsPermissionsVersioning*Next we need to connect activity workers to SWF by packaging your logic into an external process which polls the service as Alan described earlier.*You need to take your logical model for the workflow,

the stateless function that translates what happened before to what should happen next,

and express it in that external Decider process.

This Decider process needs to be setup to poll the service for new and interesting histories to make decisions on.*Last step is to kick off your workflows.

But I want to go back a step and focus more on how users can approach the modeling part to then walk through workflow execution.*So you want to model a workflow with SWF and dont know where to start.

Lets look first at concepts which are important to designing any complex system.*You are all aware of the famous GOF patterns for designing software.

These patterns cover common practices to design software in a way which is not bound to any one language.

These patterns are used as the logical building blocks for applications.

Variety of categories of patterns, such as creational patterns like Singleton or Factory Method.

Also structural patterns like Faade.

Even behavioral patterns like Visitor.

Also other categories, but you get the point.*Just like in designing software, there are common practices in designing distributed multi-step applications.

Instead of building blocks for software, these patterns deal with building blocks for higher-level orchestrations between software applications.

Just like software patterns, workflow patterns are broken up into categories based on the part of the conceptual space they tackle.

For example, there are control patterns which deal with the flow of actions within a workflow, like Sequence, Parallel Split, and Synchronization.

There are data handling patterns affecting how data flows through the workflow, like Data-based Routing and Scope Data.

There are patterns dealing with how exceptional conditions are handled, like Deadline Expiry.

And there are patterns dealing with how resources are used during the execution of a workflow, like Retain Familiar.*These workflow patterns have been collected and documented in a join effort by a team out of Eindhoven University of Technology lead by Professor Wil Van Der Aalst and another team out of Queensland University of Technology lead by Professor Arthur ter Hofstede.

There is much more about workflow patterns than I will be able to cover in this talk. If you go to the website for this project, workflowpatterns.com, you can find links to specifics on each pattern, example applications of the patterns, and paper after paper on analysis of workflow patterns.*Now, lets get into the meat of how workflows build around these patterns execute using SWF.*As part of this walkthrough well highlight different patterns we are modeling in SWF and how they are expressed using SWF primitives.

Well structure each explanation as centered around each of these Control patterns.*Well start with the Sequence control pattern.*As you can probably imagine, the Sequence control pattern is the simplest of all control patterns. This is where all modeling begins.

The Sequence pattern is most often used in concert with other patterns to form complex workflows.

As a bonus, well touch on another interesting pattern as part of this walkthrough, the Task Data pattern.

Specific features:

Scheduling of activities with dataInterpreting the history of events*Well start our walkthrough using the Sequence pattern from its very beginning, with a user process that wants to kick off the execution of a workflow.

First we have the SimpleWorkflow service sitting out there waiting for service method requests.

Weve got a user process, potentially:

some script sitting in your corporate network or maybe running in EC2,

or a sweeper process looking at rows in your database,

or even a human, like we have here, clicking on a link on a web page which the web application processes by kicking of a workflow.

This process could have logic dictating that it needs to kick of a specific workflow when a certain action is taken or certain data is encountered, such as when a new file appears in an S3 bucket.

Regardless of where the request is initiated, to start a new workflow instance, the user process makes a call to the service using the StartWorkflowInstance service method.

This call to the service is handled by creating a record in our backend store for the new workflow instance that the user process is kicking off.

What is a workflow instance you might ask? Each execution of a workflow registered with SWF is called a workflow instance by the SWF system.

So keep in mind this difference as you hear us talk about SWF:

workflows are long lived entities registered with our service representing named multi-step applications

and workflow instances are instantiations of those workflows.

As part of this record is a history of all events that have occurred for that particular workflow instance.

The audit of actions starts with the first two events in a workflow:

First, an event representing the start of the instance

and second an event representing a workflow task that indicates that a decision needs to be made to push forward the execution of the workflow.*The service is also periodically getting requests from the Decider component.

These poll requests come in the form of long poll calls to the PollForWorkflowTask service method.

The service responds to these requests with an indication whether a decision needs to be made on a workflow instance for the particular workflow the decider cares about.

In this case we have a brand new history which is pending a decision, so the full history will be passed back to that Decider to begin the decision making process.*The Decider takes the history returned from the service,

applies its internal functional mapping between history and decisions,

and comes up with a list of decisions to enact.

Our functional mapping is pretty simple here:

we saw that there was only a StartWorkflowInstance event in the history and that A1 has not yet been scheduled

so the decision here is to schedule the activity A1.

The Decider packages up this information in a response back to the service and calls the RespondWorkflowTaskCompleted service method passing the set of decisions.

The service processes the decisions and records the fact that the decisions have been made into the history of events.*Weve also got activities periodically polling the service, like the activity A1 here.

The activities call the PollForActivityTask service method with information about the specific activity they can handle.

The service responds with information about whether or not the activity should execute its logic.

In this case, there is a task waiting based on the scheduling of A1 by the Decider.

Activity schedulings can have data attached to them by the Decider which is only relevant for the single execution of the specific task during the workflow execution. This is how the Task Data pattern is expressed, through scheduling of data for specific tasks in your workflows.

So the activity has the information it needs and has started executing, so we mark in the history that as far as the service is concerned the activity task has started.*So the activity A1 is executing its logic completely outside the context of the service.

Since the service needs to know when the activity is done executing, activity workers need to respond back to the service indicating that their execution is complete.

This response can also include data which is sent back into the service.

The service handles the response by creating new events in the history.

The data which was passed back as part of the response is attached to the event which most closely corresponds with where it came from, in this case the ActivityTaskCompleted event.

Since we had a WorkflowTask scheduled as a result of this completion, the next time the Decider polls they will get this history, make another decision, and so on until the workflow gets to the close step.*Now lets take the same sequence pattern and add an additional pattern on top to show some more interesting behavior, structure loops.*Deals with the bounded re-execution of steps or collections of steps.

To make our example simple, Ill walkthrough the retry of a single step.

Also cover Deadline Expiry exception handling pattern by making the retry logic based on the failure of the activity to finish executing in a certain amount time.

Specific features:

Activity timeoutsRescheduling of activities with unique identifiers*Jumping ahead, lets say our next step in the sequence, A2, has been scheduled and is picked up by a poller for the A2 activity.*But this time,

instead of finishing its execution

the process just dies.

the executing activity never gets a chance to respond back to the service to let us know its completed.*The service internally is keeping track of every activity execution with a timer.

If the timer fires before the activity has completed, then the service will mark the activity as finished

by adding a timeout event to the history.

This is the expression of the Deadline Expiry pattern, where you specify a certain deadline for the activity task execution when you schedule the activity in the Decider.

The next Decider process to poll will get back this new history showing the timeout.*The Decider process takes the history showing the timeout, applies its internal functional mapping which in this case says we should reschedule the activity up to n times.

Weve only executed it once and timed out, so the rescheduling of A2 is the only decision to make.

This rescheduling is given a new unique identifier, specific to this additional execution of A2, which can be either picked by the Decider or generated by the service.

The service receives the new scheduling, records it in the history, and makes it available to the next activity poller.*The next time a poller for the A2 activity calls the service, we return the newly rescheduled task to that poller.

This could be the same poller which came back to life, or could be a completely separate poller process from the first poller who died. In this case it doesnt matter who picks up the task.*The new execution of A2 does its work

packages its results

And calls back to the service, which this time goes through succesfully.*Next time the Decider gets the history, they will see

The original timeout of the first execution

The fact that the next execution of A2 completed

And now can make the decision to schedule A3.*Next pattern well talk about, Exclusive Choice with Simple Merge, has a fancy name for a very straightforward concept.*This pattern deals with choosing one step or set of steps over another.

The choice of which step to execute can be based on a number of factors, like the results of a previous step execution, overall workflow state, or even based on execution time of the workflow.

Once the alternate branch is done executing, the forward flow of execution for the workflow merges back with the standard path.

In this simple example, Ill use the failure of the A2 activity as the determining factor of which path to choose.

Well also highlight the Data-based Routing pattern and how it deals with the routing of tasks based on specific data.

Specific features:

Explicit failure notificationData passing and persistence*We have a poller for the A2 activity which gets a task back to execute.*A2 starts its execution, but this time

There is an internal failure during the execution which A2 can recognize and handle.

Since the failure is handled, A2 can indicate this specific type of failure back to the service by including details about the failure in its response.

The activity responds back to the service, but this time the response is a different method callback than the successful completion, the RespondActivityTaskFailed method.

The service receives this different response and adds a different event to the history signifying the failure of the A2 activity.*The next time the Decider polls, he gets back this history showing the failure of A2.*This time when the Decider applies its logical mapping,

the failure of A2 results in the scheduling of A4.

This is the expression of the Data-based Routing pattern, where the logic in the Decider changes the flow of the execution based on the specific failure that was returned from the previous step.

Another interesting thing here is that the A4 activity could be a simple activity or could even be another workflow with complex logic about how to handle the failure of A2.

As far as the Decider is concerned, these actions are both activity schedulings and are treated the same in the Decider logic.

The Decider responds back to the service with the scheduling of A4, and the workflow progresses from there.

Once A4 is done, the control flow in our example merges back with the main execution path and the workflow closes.*Now lets look at a more complex pattern dealing with doing multiple things at once.*The Parallel Split pattern deals with executing two or more steps or sequences of steps at once.

Each of these parallel executing paths are called branches of the split.

We will use the Synchronization pattern to merge these parallel branches back to a single forward branch only once both of the branches have completed executing.

As a bonus well also look at how the Scoped Data pattern applies to data passed to specific branches.

Specific features:

Recording split/joinScheduling with split/join infoBranch-scoped data*Starting at the beginning of this new workflow model, lets look at what the Decider does when it encounters a split in execution.*The Decider takes the history showing that the workflow has started, performs its functional mapping,

and in this case decides to schedule both A1 and A2 in parallel.

The decisions being made are Record Split, Schedule A1, and Schedule A2.

The Decider sends these decisions back in its response

And the service records those decisions being made and makes available a task for both A1 and A2 at the same time.*This could happen in any order, but lets say that A1 is the first activity to poll the service and pick up its task.

It will start executing and this is recorded by the service.*Lets say that A2 polls right after and also starts executing in parallel with A1.*This could also happen in any order, but lets say that A1 is the first to finish.

This completion is just like any other completion of an activity in that it results in a decision being scheduled for the workflow .*While A2 is still executing, the Decider will get the new history showing the completion of A1.*The Decider takes the history showing A1 completed,

but the logical model for the workflow dictates that both A1 and A2 must complete before we join and schedule A3.

So the decision here is actually to do no additional tasks just yet.

This becomes an empty decision list which is passed back as part of the response to the service.

So our workflow task completes, but no other actions are recorded in the history.*Now A2 completes and another workflow task is scheduled for the Decider to make a decision.*The Decider gets this history showing both A1 and A2 completed.*The Decider applies its logical model, sees both completions

And decides to record that the split is now joined back to one branch and schedules the execution of A3.

This is sent back to the service, and the history audits all of this with the execution of A3 being the next executable step.*Now lets look at one last pattern which I saved for last due to the fact that it uses the largest number of supports to express the pattern, Persistent Trigger.*The Persistent Trigger pattern deals with triggers from external processes,

outside of the normal participants in the workflow, the Activities and the Decider, that wants to some how inject additional information into the workflow.

Triggers come in the form of signals to specific executing workflow instances.

Workflow can wait for a period of time for the signal to come in on the workflow instance.

As a bonus well cover how the Event-based Task Trigger pattern applies in this example.

Specific features:

Signaling workflow instancesMarking signals as handled using signal completionScheduling activities to execute after a delayCancelation of activities*Lets start with our A1 activity completing its execution and the Decider getting this history.*The Decider applies its logical model and in this case sees that it must wait a period of time for a specific signal.

The decision to wait is handled by using a scheduling of a special built-in activity part of the service, the Empty activity

Which can be scheduled to execute after a delay just like any other user activity registered with the service.

The completion of the delayed empty activity, which were calling Wait, will indicate to the Decider that the time has elasped to wait for the signal.

This decision is sent to the service and we record in the history that the Empty activity Wait is scheduled but not yet started due to its delay.*Lets say a user process wants to send information into our executing workflow.

They do this by calling the service with the SignalWorkflowInstance service method.

Our service records this call as just another event in the history which the Decider needs to make a decision on.

This is an expression of that pattern we mentioned, the Event-based Task Trigger.*The Decider gets the history showing the signal being recorded with the specific data that the user passed in during the call to signal.*The Decider applies its logical model and decides to do a number of things

We need to mark that the signal was handled by a decider

We need to cancel the Wait activity, which is running as an Empty activity built-in the service, that can be canceled just like any other activity while its scheduled or executing.

And we need to schedule the next step A2 using the data we got from the signal.

All of this is recorded in the history and the scheduling is made available.*Now, we could simply not get the signal.

What happens here?

Well, thats up to the Decider.

It could just go on with the flow, close the workflow, whatever it sees fit.*Add graphic showing a variety of other patterns*You may be wondering at the complexity of expressing all of these patterns in Decider logic. We have recognized this need and have developed

Take the compositional aspect which is obvious in patterns and remove all the boilerplate code***