Amazon Mechanical Turk is part of AWS

Q: What is Amazon SWF?
Simple Workflow Service (Amazon SWF) is a web service that makes it easier to coordinate work across distributed application components. With Amazon SWF, you can design applications for a variety of use cases, such as media processing, web application backends, business process workflows, and analysis pipelines, as a collection of coordinated tasks. Tasks are calls to various processing steps in an application that can be performed by executable code, web service calls, user actions, and scripts.

The coordination of tasks requires the management of execution dependencies, scheduling and simultaneity according to the logical flow of the application. With Amazon SWF, developers have complete control over implementing the processing steps and coordinating the tasks that drive those steps without worrying about the underlying complexities, such as: B. having to track the success of the individual steps and manage their status. Amazon SWF also provides the AWS Flow Framework, which enables developers to use asynchronous programming when developing their applications. With the help of Amazon SWF, developers can take advantage of features that make programming easier and can improve resource utilization, latency, and throughput of their applications.

Q: What are the benefits of designing my application as a set of coordinated tasks?How does Amazon SWF help me?
In Amazon SWF, tasks are calls to logical steps in applications. Tasks are processed by contractors. Contractors are programs that interact with Amazon SWF and receive tasks, process them, and return their results. A contractor implements a processing step of an application. You can create contractors in different programming languages ​​and even reuse existing components to quickly create the contractor. You can e.g. B. Use cloud services, enterprise applications, legacy systems, and even simple scripts to implement contractors. Since you can control the number of job recipients for processing each individual task type independently, you can efficiently control the throughput of your application.

In order to coordinate the application execution by the individual contractors, create a program in the programming language of your choice, which is known as the decision maker. The separation of the processing steps and their coordination enables the controlled management of your application and gives you the flexibility to provide, execute, scale and update the individual processing steps independently of one another. You can deploy contractors and decision-makers either in the cloud (e.g. Amazon EC2 or Lambda) or on computers behind corporate firewalls. By decoupling contractors and decision-makers, your company logic can be controlled dynamically and your application can be quickly updated and adapted to new requirements. For example, you can remove, skip, or rerun tasks and create new application flows simply by changing the decision maker.

By implementing contractors and decision-makers, you can concentrate on your differentiated application logic as far as it relates to the execution of the actual processing steps and their coordination. Amazon SWF processes the underlying details such as: B. Storing the tasks until they are assigned, monitoring the assigned tasks and providing consistent information on their completion. Amazon SWF also provides ongoing visibility at the level of each task through APIs and a console.

Q: What can I do with Amazon SWF?
With Amazon SWF, you can overcome many challenges in building applications with distributed components. For example, you can use Amazon SWF and its associated AWS Flow Framework to:

  • Build your applications as asynchronous programs using simple programming constructs to abstract details such as: B. Initiate tasks that are performed remotely and keep track of the runtime status of the program.
  • Manage the execution status of your application (e.g. which steps have been completed, which are currently being executed, etc.). You don't need to use databases, custom systems, or ad hoc solutions to save the execution status.
  • Communicate and manage the workflow between your application components. With Amazon SWF, you don't need to design a messaging protocol or worry about missing or duplicating tasks.
  • Centralize the coordination of the steps in your application. Your coordination logic does not have to be distributed over different components, but can be implemented in a single program.
  • Integrate a range of programs and components, including legacy systems and third-party cloud services, into your applications. Since you can flexibly decide where and in what combination the application components are provided for your application, Amazon SWF supports you in the gradual migration of the application components from private data centers to the public cloud infrastructure without interrupting the availability of the application or reducing its performance affect.
  • Automate workflows that include time-consuming, user-performed tasks (e.g. approvals, reviews, investigations, etc.). Amazon SWF reliably tracks the status of processing steps that can take several days or months.
  • Create an application tier above Amazon SWF to support domain specific languages ​​for the end users. Because Amazon SWF gives you complete flexibility in your choice of programming language, you can easily create interpreters for specialized languages ​​(such as XPDL) and custom user interfaces, including modeling tools.
  • Integrate detailed booking control and visibility into all running instances of your application. You can also incorporate the visibility capabilities provided by Amazon SWF into your own user interfaces using the Amazon SWF APIs.

Customers have used Amazon SWF to build applications for video encoding, social commerce, infrastructure delivery, MapReduce pipelines, business process management (BPM), and various other use cases. For more information on use cases, see "Can you name some of the use cases that Amazon SWF can solve?". For information on how customers are using Amazon SWF today, check out our case studies.

Q: What are the advantages of Amazon SWF over custom solutions and existing workflow products?
When creating solutions to coordinate tasks in a distributed environment, developers need to consider several variables. Tasks that control processing steps can take a long time and result in errors, timeouts, or restarts. They are often completed with different throughputs and latencies. Tracking and visualizing tasks in all of these cases is not only a challenge, but also undifferentiated work. As applications and tasks grow, developers of distributed systems often face difficult problems. You have to z. B. ensure that a task is only assigned once and that its result is reliably tracked even in the event of unexpected errors and failures. Developers can focus on fine-grained application logic when using Amazon SWF; H. how the tasks are processed and coordinated.

With existing workflow products, developers are often forced to learn specialized languages, host expensive databases, and relinquish control of task execution. The specialized languages ​​make it difficult to create complex applications and are not flexible enough to make changes quickly and efficiently. Amazon SWF, on the other hand, is a cloud-based service that allows the use of common programming languages ​​and gives developers control over where the tasks are processed. By adopting a loosely coupled model for distributed applications, it is quick and easy to make changes in Amazon SWF.

Q: What are contractors and decision makers?
In Amazon SWF, an application is implemented by creating multiple contractors and a decision maker. These communicate directly with the service. Contractors are programs that interact with Amazon SWF to receive tasks, process received tasks, and return results. The decision maker is a program that controls the coordination of the tasks, i. H. their order, simultaneity and timing according to the application logic. The contractor and the decision maker can use cloud infrastructure, e.g. B. Amazon EC2, or on computers behind firewalls. Amazon SWF mediates the interactions between the contractor and the decision maker. It enables the decision maker to obtain consistent insights into the progress of the tasks and to continuously initiate new tasks. At the same time, Amazon SWF stores tasks, assigns them to contractors when they are ready, and monitors their progress. It ensures that a task is only assigned once and never duplicated. Because Amazon SWF continuously manages the status of the application, the contractors and decision-makers do not need to keep track of the execution status. They can run independently and scale quickly. On the Amazon SWF detail page, see the Functionality section for more information about the steps to create applications with Amazon SWF.

You can run a workflow multiple times in Amazon SWF at the same time. Each execution is referred to as a "workflow execution" or "execution". Executions are identified by unique names. You can use the Amazon SWF Management Console (or the Visibility APIs) to view your executions as a whole or detailed information about a specific execution at the task level.

Q: What are the features of Amazon SWF to make it easy to program applications?
Just like other AWS services, Amazon SWF provides a core SDK for the web service APIs. In addition, Amazon SWF provides an SDK, the so-called AWS Flow Framework, with which you can quickly and easily create Amazon SWF-based applications. The AWS Flow Framework abstracts the details of the coordination at the task level through familiar programming constructs. While your program is running, the framework makes calls to Amazon SWF, keeps track of the execution status of your application using the execution history stored by Amazon SWF, and calls the relevant parts of your code at the right time. The AWS Flow Framework provides an intuitive programming environment for accessing Amazon SWF and enables developers to program entire applications as asynchronous interactions structured in a workflow. For more details, see What is the AWS Flow Framework?

Q: When should I use Amazon SWF and when should I use AWS Step Functions?

AWS Step Functions is a fully managed service that simplifies the coordination of the individual components of distributed applications and microservices through visual workflows. Instead of writing a decision-making program, you define state machines in JSON. For new AWS applications, it is definitely advisable to test Step Functions. If you find that Step Functions is not meeting your needs, simply switch back to Amazon Simple Workflow (SWF). Amazon SWF gives you complete control over your orchestration logic, but it adds complexity to application development. Here you can write decision-making programs in the programming language of your choice or use the flow framework with its programming constructs that structure asynchronous interactions for you. AWS continues to provide the Amazon SWF service and flow framework and continues to support all Amazon SWF customers.

Q: How is Amazon SWF different from Amazon SQS?

Amazon SQS and Amazon SWF are both services that make it easy to integrate applications and microservices:

  • Amazon Simple Queue Service (Amazon SQS) provides reliable, highly scalable, hosted queues for storing messages while they are routed between applications or microservices. With Amazon SQS, you can move data between distributed application components, making them easier to decouple.
  • Amazon Simple Workflow Service (Amazon SWF) is a web service that makes it easier to coordinate work across distributed application components.

The main differences between Amazon SQS and Amazon SWF are as follows:

  • Amazon SWF API actions are task-oriented. Amazon SQS API actions are message oriented.
  • Amazon SWF tracks all tasks and events in an application. With Amazon SQS, you need to implement your own application-level tracking, especially if your application uses multiple queues.
  • The Amazon SWF console and visibility APIs provide an application-centric view that you can use to search for executions, view details of an execution, and manage executions. With Amazon SQS, such additional functions must be implemented.
  • Amazon SWF provides many features that make application development easier, such as: B. the transfer of data between tasks, signals and flexibility in the distribution of tasks. With Amazon SQS, you need to implement some functionality at the application level.
  • In addition to a core SDK for calling the service APIs, Amazon SWF provides the AWS Flow Framework, which you can use to build distributed applications using programming constructs to structure asynchronous interactions.

While you can use Amazon SQS to create basic workflows to coordinate your distributed application, Amazon SWF has this functionality out of the box, along with other application-level functionality.

Familiarize yourself with Amazon SQS and Amazon SWF to help you decide which solution suits your needs.

Q: Can you name a few use cases that can be solved with Amazon SWF?

Amazon SWF has been used in use cases in the areas of media processing, business process automation, data analysis, migration to the cloud, and batch processing. Some examples:

Use case # 1: Video encoding using Amazon S3 and Amazon EC2. In this use case, large videos are uploaded to Amazon S3 in units. The upload of the units must be monitored. After a unit is uploaded, it is encoded by downloading it into an Amazon EC2 instance. The encoded unit is stored in another Amazon S3 storage. After all units have been encoded in this way, they are combined into a complete encoded file and completely restored back to Amazon S3. During this process, errors can occur in one or more units due to coding errors. Such errors must be recognized and dealt with.

With Amazon SWF: The entire application is built as a workflow, with each video file treated as a workflow execution. The following tasks are handled by the various contractors: uploading a unit to Amazon S3, downloading a unit from Amazon S3 to an Amazon EC2 instance and encoding the unit, restoring a unit back to Amazon S3, combining multiple units into a single file, and uploading the complete file to Amazon S3. The decision maker initiates simultaneous tasks in order to take the parallelism into account in the use case. It initiates a task to encode an uploaded unit without waiting for the remaining units to be uploaded. If a task fails for a unit, the arbiter reruns the task for that unit only. The application status saved by Amazon SWF helps the decision maker control the workflow. For example, the decider uses the application status to determine when all units were encoded and to determine their Amazon S3 storage so that the individual units can be combined into the overall file. The progress of the execution is continuously tracked in the Amazon SWF Management Console. When failures occur, the specific failing tasks are identified and used to locate the failing devices.

Use Case # 2: Processing Large Product Catalogs Using Amazon Mechanical Turk. When validating data in large catalogs, the products in the catalog are processed in batches. Different batches can be processed at the same time. For each batch, the product data is extracted from the servers in the data center and converted into the CSV files (Comma Separated Values) required by the Amazon Mechanical Turk RUI (Requester User Interface).The CSV is uploaded to populate and run the HITs (Human Intelligence Tasks). When the HITs are complete, the resulting CSV file is converted back to bring the data back to its original format. The results are then scored and the Amazon Mechanical Turk employees are paid for error-free results. Errors are sorted out and processed again, while the error-free HIT results are used to update the catalog. While processing the batches, the system must track the quality of Amazon Mechanical Turk employees and adjust payments accordingly. Bad HITs are processed again and sent back down the pipeline.

With Amazon SWF: The use case described above is implemented as a set of workflows. A BatchProcess workflow handles processing for a single batch. He has contractors who extract, transform, and send the data through Amazon Mechanical Turk. The BatchProcess workflow returns the error-free and defective HITs. These are used as input for three further workflows: MTurkManager, UpdateCatalogWorkflow and RerunProducts. The MTurkManager workflow executes the payments for error-free HITs, replies to the employees who produced defective HITs, and updates its own database to keep track of the quality of the results. The UpdateCatalog workflow updates the master catalog based on error-free HITs. The RerunProducts workflow waits until there is a sufficiently large batch of products with defective HITs. Then it creates a batch and sends it back to the BatchProcess workflow. All end-to-end catalog processing is performed by a CleanupCatalog workflow, which initiates sub-executions of the above workflows. A system of well-defined workflows enables this use case to be systematically built, monitored, and executed for catalogs with several million products.

Use case # 3: Migrating components from the data center to the cloud. Business-critical processes are hosted in a private data center, but must be completely migrated to the cloud without any interruptions.

With Amazon SWF: Amazon SWF-based applications can combine contractors who package components running in the data center with contractors running in the cloud. In order to seamlessly migrate a contractor from a data center, new contractors of the same type are first made available in the cloud. The contractors in the data center will continue to run as usual, together with the new cloud-based contractors. To test and validate the cloud-based contractors, some of the traffic is routed through them. There are no application interruptions during these tests because the contractors in the data center are still running. After successful tests, the contractors in the data center are gradually decommissioned and the contractors are scaled up in the cloud until they are gradually executed completely in the cloud. This process can be repeated for all other contractors in the data center so that the application is completely moved to the cloud. If, for any business reasons, certain processing steps must continue to be carried out in the private data center, this can be done without problems and the relevant contractors can still be part of the application.

For more exciting applications and systems developers and businesses are building with Amazon SWF, check out our case studies.

Q: Does Amazon use Amazon SWF for its own applications?
Yes. Developers at Amazon use Amazon SWF for a wide range of projects and millions of workflow runs every day. Use cases include key business processes behind the Amazon.com and AWS websites, implementations for various AWS web services and their APIs, MapReduce analytics for operational decision-making, and managing user-accessible content such as websites, videos and Kindle books .

Q: What are the first steps to use Amazon SWF?
To sign up for Amazon SWF, go to the Amazon SWF detail page and click the Sign Up Now button. If you do not have an Amazon Web Services account, you will be asked to create one. After signing in, you can take a sample tour in the AWS Management Console that explains step-by-step how to run a simple application to convert images with Amazon SWF. You can also download the AWS Flow Framework samples to learn more about the various features of the service. To get started using Amazon SWF in your applications, see the Amazon SWF documentation.

Q: Are there any sample workflows I can use to test Amazon SWF?
Yes. As a first step with Amazon SWF, you can take the sample tour in the AWS Management Console, which explains how to register a domain and types, how to provision contractors and decision makers, and how to start workflow executions. You can download the code for the contractors and decision makers described in this tour, run them on your infrastructure, and even make changes to build your own applications. You can also download the AWS Flow Framework samples, which illustrate how to use Amazon SWF for various use cases, such as: B. distributed data processing, cron jobs and provision of application stacks. By looking at the source code included, you can learn more about what Amazon SWF can do and how to use the AWS Flow Framework to build your distributed applications.

Q: What are the different ways to access SWF?
You can access SWF in one of the following ways:

  • AWS SDK for Java, Ruby, .NET, and PHP
  • AWS Flow Framework for Java (included in the AWS SDK for Java)
  • Amazon SWF web service APIs
  • AWS Management Console

Q: What is the registry?
Registration is a one-time step for all different types of workflows and activities. You can register either through a program or through the Amazon SWF Management Console. During registration you enter unique IDs for each activity and each workflow type. You also set default information that is used when running a workflow, such as: B. Values ​​for time limits and parameters for task distribution.

Q: What are domains?
In SWF, you define logical containers, called domains, for your application resources. Domains can only be created at the level of your AWS account and cannot be nested. A domain can be given any custom name. Each application resource, for example a workflow type, an activity type or an execution, belongs to exactly one domain. During registration, you specify the domain under which a workflow or activity type is to be registered. When you start an execution, it is automatically created in the same domain as the associated workflow type. The uniqueness of resource identifiers (e.g. type IDs, execution ID) applies to the scope of a domain, i.e. In other words, you can use the same IDs in different domains.

Q: How can I manage my application resources across different environments and groupings?
You can use domains to organize your application resources so that they are easier to manage and do not inadvertently interfere with one another. For example, you can create different domains for your development, test, and production environments and the appropriate resources in each of these environments. Although you might register the same type of workflow in each of these domains, it will be treated as a separate resource in each domain. You can change its settings in the development domain or manage executions in the test domain without affecting the corresponding resources in the production domain.

Q: How does a decision maker coordinate a workflow in Amazon SWF?
The decision maker can be seen as a special type of contractor. Just like the contractors, a decision maker can be written in any language and requests tasks from Amazon SWF. However, it processes special tasks, so-called decision tasks. Amazon SWF emits decision tasks whenever there is a transition in a workflow execution, such as: B. the completion of an activity task or a timeout. A decision task contains information on inputs, outputs and the current status of the previously initiated activity tasks. The decider uses this data to decide what to do next, such as new activity tasks, and feeds their decision back to Amazon SWF. Amazon SWF in turn implements these decisions by initiating new activity tasks, if necessary, and monitors them. By continuously reacting to decision-making tasks, the decision-maker controls the sequence, timing and simultaneity of activity tasks and thus the execution of the processing steps in the application. SWF issues the first decision task when an execution starts. From this point on, Amazon SWF implements the decisions made by the decision maker and thus controls the execution. Execution continues until the approver makes the decision to stop execution.

To support the decision maker in his decision making, SWF maintains a continuous record with the details of all tasks in an execution. This data set is known as the history and is unique for each execution. A new process is initiated each time an execution is started. At this point the history contains initial information, e.g. B. the input data of the execution. Later, when the contractors process the activity tasks, Amazon SWF updates the history with their input and output dates and their respective status. When an approver receives an approval task, he can review the progress of its execution. Amazon SWF ensures that the history correctly reflects the execution status at the time the decision task was issued. The decision maker can use the history to determine what has already happened in the execution and then decide on the appropriate next step.

Q: How can I ensure that a contractor or decision maker only receives tasks that he understands?
You use task lists to determine how tasks are assigned. Task lists are Amazon SWF resources to which initiated tasks are added and from which tasks are retrieved. Task lists are identified by user-defined names. A task list can contain tasks of different type IDs, but they must be either activity or decision tasks. During registration, you define a standard task list for each activity and workflow type. You can also create task lists at run time in Amazon SWF. All you have to do to create a task list is give it a name and start using it. You use task lists as follows:

  • When initiating an activity task, an approver can add that task to a specific task list or ask Amazon SWF to add it to the default task list for its activity type.
  • At the start of an execution, you can ask Amazon SWF to add all decision tasks to a specific task list or to the default task list for the workflow type.
  • When requesting tasks, decision-makers and contractors specify the task list from which they want to receive tasks. If a task is available in the list, SWF sends it in the response and also provides its type ID.

Based on the information above, you control which task list a task is added to and who pulls tasks from each list. In this way, you ensure that contractors and decision-makers only receive the tasks that they understand.

Q: What is the AWS Flow Framework?How does it help me coordinate my workflow?
AWS Flow Framework is a programming environment for developing Amazon SWF-based applications quickly and easily. AWS Flow Framework abstracts the details of task-level coordination and asynchronous interaction through familiar programming constructs. To coordinate workflows in Amazon SWF, remote actions that take different times to complete (such as activity tasks) must be initiated and the dependencies between these actions properly implemented.

With the AWS Flow Framework, both facets of coordination can be conveniently expressed through familiar programming concepts. For example, initiating an activity task is as easy as calling a method. AWS Flow Framework automatically translates the call into a decision to start the activity task. Amazon SWF then takes control and assigns the task to a contractor, monitors it, and sends feedback when the task is complete. The framework provides you with the result of the task, including the output data, in the code as return values ​​of the method call. To express the dependencies of a task, just use the return values ​​in your code, as with traditional method calls. The framework runtime automatically waits for the task to complete and does not continue executing until the results are available. In the background, the framework's runtime receives contractor and decision-making tasks from Amazon SWF, calls the relevant methods in your program at the right time, and formulates decisions that are sent back to Amazon SWF. Because the AWS Flow Framework enables access to Amazon SWF through an intuitive programming environment, you can easily incorporate asynchronous and event-driven programming into your application development.

Q: How do contractors and decision makers communicate with Amazon SWF?Aren't poll logs particularly resource-intensive?
Typically, developers need to determine the optimal polling frequency for poll-based protocols. If polled too often, many of the polls can be returned with empty results. As a result, the calls consume a large portion of application and network resources without generating meaningful output to continue execution. On the other hand, if the polling frequency is too low, the messages may be kept available longer, which increases the application latency.

To remedy the efficiency deficiencies associated with polling, Amazon SWF provides what is known as long polling. Long polling dramatically reduces the number of polls that are returned without a task. If the contractor and decision maker send task calls to Amazon SWF and no tasks are available, the connection is maintained for one minute. If a task becomes available within this time, it is returned in response to the long poll request. By maintaining the connection for a certain period of time, repeated polls with empty results are avoided. With long polling, your applications benefit from the advantages that polling offers in terms of security and data flow control, without foregoing the latency and efficiency advantages of push-based web services.

Q: Can I use an existing web service as a contractor?
Contractors use standard HTTP GET requests to pull tasks from Amazon SWF and return the results. To use an existing web service as a contractor, you can program a wrapper that pulls tasks from Amazon SWF, calls your web service's APIs if necessary, and returns the results to Amazon SWF. In the wrapper, the input data provided in a task is translated into the parameters for the APIs of your web service. Likewise, the output data from the web service APIs is translated into the results for the task and returned to Amazon SWF.

Q: Does Amazon SWF limit me to using certain programming languages?
No, you can create the contractors or decision makers in any programming language as long as communication with Amazon SWF is supported via web service APIs. The AWS SDK is currently available in Java, .NET, PHP, and Ruby. The AWS SDK for Java includes the AWS Flow Framework.

Q: I want to make sure that there is only one execution for each activation of my business process (e.g. a transaction, transfer, or assignment). How can I achieve this?
When you start a new workflow run, you provide an ID for that workflow run. In this way, you assign the execution of a business unit or business action (e.g. a customer ID, a file name, a serial number). Amazon SWF ensures that the ID of an execution only exists once during the execution.During this time, an attempt to start another run with the same ID will fail. This makes it easy for you to meet business needs that require a specific business action, such as: B. a transaction, transfer or assignment, never multiple executions occur. Let's consider a workflow for registering a new user on a website. When a user clicks the submit button, the execution is named and uniquely identified by the user's email address. If the execution already exists, the call to start the execution will fail. No additional code is required to prevent conflicts that can arise if a user clicks Submit multiple times during the registration process.

After the workflow execution is completed (successful or not), you can start another workflow execution with the same ID. This leads to a rerun of the workflow execution with the same execution ID but a different pass ID. The pass ID is generated by Amazon SWF and multiple executions with the same workflow execution ID can be distinguished using the pass ID. Because Amazon SWF allows the workflow execution ID to be reused in this way, you can treat use cases like retries. Assume that the workflow execution in the user registration example above encountered an error while creating the database record for the user. The workflow execution can now be started again with the same execution ID (the email address of the user) and a new ID does not have to be created to retry registration.

Q: How does Amazon SWF help me scale my applications?
Amazon SWF helps you scale your applications by giving you complete control over the number of contractors running for each type of activity and the number of instances running for a decision maker. By increasing the number of contractors or decision-making bodies, you increase the computing resources allocated to the corresponding processing steps and thus the throughput for these steps. You can use the runtime data provided through the Amazon SWF APIs to perform automatic scaling. For example, Amazon SWF captures B. the number of tasks in a task list. An increase in this number suggests that contractors are unable to keep up with the traffic. So you can automatically start new contractors as soon as the backlog of tasks exceeds a threshold.

Q: I run a large number of business-critical applications. How can I monitor and scale these?
In addition to the AWS Management Console, Amazon SWF provides a wide variety of visibility APIs. You can use these visibility APIs to get runtime information to monitor all executions and automatically scale the executions based on traffic. You can get detailed data on each type of workflow, e.g. B. the number of open and closed executions in a certain period of time. You can also create your own custom monitoring applications using the visibility APIs.

Q: There are a large number of runs in my application all the time, but some of them often fail or get stuck. How can I identify these problematic executions and correct the problems?
You can search for executions in Amazon SWF using the AWS Management Console and Visibility APIs. You can search by various criteria, such as the time interval at which executions started or completed, the current status (open or closed), and standard error modes (e.g. timed out, terminated). To group workflow executions, you can define up to 5 tags to assign workflow executions to custom text at startup. You can use tags when browsing workflow runs in the AWS Management Console.

To find possible stopped executions, you can first start a time-based search to find executions that are running longer than expected. You can then investigate this further by viewing details at the task level and determining whether certain tasks are taking too long, have failed, or whether the approver simply did not initiate any tasks. This may help you identify the problem at the task level.

Q: I have an activity type that can be used in multiple applications. Can I share it with all of these applications?
Yes. An activity type can be shared by multiple applications, provided that the applications and the activity are registered in the same domain. To implement this release, you can have tasks for the activity type initiated by different decision makers and add the activity type to the task list to which the contractors send requests for this activity. The contractors of this activity type then receive activity tasks from the various other applications. You can use multiple task lists to see which application an activity task originated from, or to provide different sets of contractors for different applications. See also How can I ensure that a contractor or decision maker only receives tasks that he understands?

Q: Can I use AWS Identity and Access Management (IAM) to manage access to Amazon SWF?
Yes. You can give IAM users permissions to access Amazon SWF. IAM users are only allowed to access the SWF domains and APIs you specify.

Q: Can I run my contractors behind a firewall?
Yes. Contractors use standard HTTP GET requests to pull tasks from Amazon SWF and return the calculated results. Because contractors always initiate requests to Amazon SWF, you do not need to change your firewall configuration to allow incoming requests.

Q: Isn't it a security risk to reveal my business logic as a contractor and decision maker?
Contractors use standard HTTP GET requests to pull tasks from Amazon SWF and return the calculated results. Therefore, you don't need to disclose an endpoint to your contractors. In addition, Amazon SWF only submits tasks to contractors if the decision makers initiate those tasks. Since you program the decision maker yourself, you have complete control over when and how tasks are initiated and which input data are sent to the contractor with these tasks.

Q: How does Amazon SWF help me coordinate the tasks in my application reliably?
Amazon SWF provides useful guarantees around task assignment. It ensures that a task is never duplicated and ensures that each task is only assigned once. As a result, Amazon SWF only submits a given task to one contractor (or approver), even if you have multiple contractors for a particular type of activity (or a number of instances of an approver). In addition, Amazon SWF allows a maximum of one pending decision task for a workflow execution. You can therefore safely start multiple decision-making instances without two instances running at the same time for the same execution. This functionality allows you to coordinate your workflow without worrying about duplicated, missing, or conflicting tasks.

Q: How many workflow types, activity types, and domains can I register with Amazon SWF?
Each domain can have a maximum of 10,000 registered or rejected workflow and activity types, in total. You can have a maximum of 100 Amazon SWF domains (including registered and denied domains) in your AWS account. If you think you have exceeded the limits above, contact the Amazon SWF team using this form to discuss your scenario and request higher limits.

Q: Is there a limit to the number of simultaneous workflow executions?
At any point in time, a maximum of 100,000 open executions are permitted in a domain. Otherwise, there is no other limit to the cumulative number of active executions or the number of executions that Amazon SWF keeps. If you think you have exceeded the limits above, contact the Amazon SWF team using this form to discuss your scenario and request higher limits.

Q: How long can workflow executions take?
The duration of each workflow execution can be a maximum of 1 year. Each workflow execution history can contain a maximum of 25,000 events. If your use case requires exceeding these limits, you can use the capabilities provided by Amazon SWF to continue executions and structure your applications using workflow sub-executions.

Q: What if my workflow execution is idle for an extended period of time?
Amazon SWF does not take any special action if a workflow execution is idle for an extended period of time. Inactive executions are subject to the time restrictions you have configured. For example, if you set the maximum duration of an execution to 1 day, an idle execution will stop after 1 day due to the timeout. Inactive executions are also subject to the Amazon SWF limit for the maximum duration of execution (1 year).

Q: How long can a jobor take to process a task?
Amazon SWF does not have a specific time limit on how long a task can take to process a task. Amazon SWF enforces the time limit that you set as the maximum duration for the activity task. Note that because Amazon SWF limits the duration of an execution to a maximum of 1 year, a contractor cannot take more than 1 year to process a task.

Q: How long can Amazon SWF hold a task before a contractor requests it?
In Amazon SWF, there is no specific time limit for how long a task can be kept ready before it is polled by a contractor. When you register the activity type, you can set a default time limit for how long Amazon SWF keeps activity tasks of that type open. You can also set this time limit when scheduling an activity task using your decision maker code or you can overwrite the standard time limit. Since Amazon SWF limits the duration of a workflow execution to a maximum of 1 year, the task will not be kept available for longer than 1 year if no other time limit is specified.

Q: Can I schedule multiple Activity Tasks by issuing a single decision?
Yes, you can plan up to 100 activity tasks in one decision and also output several decisions one after the other.

Q: How many contractor tasks, signals, and markers can I use in one workflow run and across multiple runs?
There is no limit to the total number of activity tasks, signals, and timers used during a workflow execution. However, there can currently be a maximum of 1,000 open activity tasks per workflow execution. This includes initiated activity tasks and activity tasks that are currently being processed by contractors. Likewise, only 1,000 timers open per workflow execution and up to 1,000 open child executions per workflow execution are allowed.

Q: How much data can I transfer within a workflow execution?
There is no limit to the total amount of data transferred during a workflow execution. However, the Amazon SWF APIs apply certain maximum values ​​to the parameters used to pass data within an execution. The input data transferred to an activity task and the input data sent with a signal may contain a maximum of 32,000 characters.

Q: Does Amazon SWF keep completed runs? If so, for how long?

Amazon SWF retains the history of a completed run for the time you specify (a maximum of 90 days, which is approximately 3 months). During the retention period, you can access the history and search for execution programmatically or through the console.

Q: When are the API calls throttled?
If you place very large amounts of API calls in a very short time beyond sporadic peaks, your data traffic can be throttled. If you find that your traffic is being throttled very frequently, or that your application is experiencing frequent spikes, contact the Amazon SWF team using this form to discuss your usage scenario and request other throttling settings for your account.

Q: What regions is Amazon SWF available in?
Amazon SWF (SWF) is currently available in the following regions: US East (Northern Virginia), US West (Oregon), US West (Northern California), EU (Ireland), EU (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), South America (São Paolo), and AWS GovCloud (USA).

Q: Is Amazon SWF available across Availability Zones?
Yes, Amazon SWF manages your workflow execution history and other details about your workflows across 3 Availability Zones, so your applications will reliably run on Amazon SWF even if errors occur in one Availability Zone.

Q: What are the Amazon SWF Service Access Points?
For more information about access endpoints, see the AWS general reference documentation.

Q: Are taxes already included in the prices?

Unless otherwise stated, our prices are plus applicable taxes and duties, including VAT and sales tax. For customers with a Japanese billing address, use of AWS services is subject to Japanese consumption tax. Additional Information.