Systems and methods for providing services in a stateless application framework

This is a reissue of U.S. Pat. No. 10,732,990 B2, which issued on Aug. 4, 2020 from U.S. patent application Ser. No. 15/965,092 filed Apr. 27, 2018, the disclosure of which is incorporated herein by reference in its entirety.

The present specification generally relates to stateless applications, and more specifically, to providing a mechanism to deliver services using distributed stateless applications according to various embodiments.

Data processing systems may use state machines to keep track of states and contexts across different sessions. However, when the number of data processing requests increases, the amount of computer resources (e.g., memory and processing resources) required to run the different instances of state machines and to store the different session states or contexts also increases. Furthermore, the time required to complete a workflow within a session may vary. For example, in some instances, data processing components external to the data processing systems may be used in the workflow, and it may take an extended period of time (e.g., several minutes, several hours) for the external data processing components to provide results back to the data processing systems. Keeping the state and context data in the memory of the data processing systems while the session is in an idle state can be inefficient.

Stateless applications may be developed to improve the efficiency of the data processing systems by eliminating the need of storing the state and context data in the memory of the data processing systems. However, stateless applications present different challenges when implemented in a distributed environment. Thus, there is a need for providing a stateless application framework for developing data processing systems that overcomes problems associated with conventional systems and methods.

Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.

The present disclosure describes methods and systems for providing a stateless application framework in a data processing system. The stateless application framework includes a stateless application module, a context database, and a messaging queue in various embodiments. The stateless application framework may be utilized by different applications for implementing different workflows. Each workflow may be associated with one or more state machine configurations representing different states within the workflow. Upon receiving an indication of an event from an application, the stateless application module may initiate a corresponding workflow for the application. In some embodiments, a first instance of the stateless application module is instantiated. The first instance of the stateless application may be allocated computer resources, such as non-persistent memory (e.g., random access memory) and computer processing cycles to handle the indication of the event according to the workflow.

In some embodiments, the stateless application module may select a state machine configuration corresponding to the workflow, and assign an initial state in the configuration to the event. The stateless application module may also create, for the event, a record that includes state data (e.g., context data) that identifies a current state of the event, and may store the record in a persistent data storage (e.g., a hard drive, a flash drive, etc.), such as the context database. In some embodiments, the persistent data storage is external to the stateless application module and the application that initiated the event. By storing the state data in the persistent data storage, the state data of the event may be made available even after the first instance of the stateless application module is terminated. For example, another instance of the stateless application module may subsequently be instantiated and access the record to perform actions based on the state data in the record.

Based on the workflow associated with the event, the stateless application module may also transmit job requests to one or more data processing engines external to the stateless application module. In some embodiments, the stateless application module may retrieve the state data of the record from the context database, and include the state data in the job requests. After transmitting the job requests to the one or more data processing engines, the first instance of the stateless application module may be terminated, such that the computer resources allocated to the first instance of the stateless application module may be freed up for other processes or threads (e.g., other concurrently running instances of the stateless application module, etc.). This is especially advantageous when the time taken by the data processing engines to complete the job requests is long, as the first instance of the stateless application module does not take up the computer resources while idling and waiting for a response (such as a message) from the data processing engines.

Since the state data of the event is stored in the persistent storage, the state data is not lost, and can be made available to other instances of the stateless application module. For example, other instances of the stateless application module may access the record and update the state data of the record.

When a data processing engine completes the corresponding job request, the data processing engine may send a response to the stateless application module. The response may include the state data and other identification data that identifies the event and/or the state machine configuration associated with the event. Upon receiving the response, a second instance of the stateless application module may be instantiated to perform one or more actions based on the response. For example, the second instance of the stateless application module may update the state data of the record based on the response and the workflow (e.g., when the workflow indicates that the completion of the job request moves the event from one state to another state). In addition, the stateless application module may also transmit another job request to the same or another data processing engine based on the response, where the job request includes the updated state data from the record. Furthermore, the stateless application module may also transmit the updated state data to the application that initiates the event.

The processing performed by each of the data processing engines may be dependent on a current state of the user account within the workflow. As such, the data processing engine may perform the processing based on the state data provided in the job request. The stateless application module may also transmit different job requests to different data processing engines in parallel (e.g., when the job requests are not dependent on each other). For example, the first instance of the stateless application module may transmit job requests to the multiple data processing engines when a first state in the state machine configuration is assigned to the event. Further, while a first data processing engine is still performing the requested processing, a second data processing engine may complete the processing and may transmit a response to the stateless application module, which causes the second instance of the stateless application module to update the status data of the record (e.g., changing the state of the event from the first state to a second state). As a result, when the first data processing engine returns with a response to the stateless application module, the stateless application module may attempt to perform an inaccurate update to the status data in the record. Furthermore, the tasks that the first processing engine performed for the event may be incorrect since the tasks were performed based on the event in the first state, and not in the second state.

Thus, according to various embodiments of the disclosure, a locking pattern mechanism is employed to ensure that the state data stored in the context database is consistent and that the tasks performed by the various data processing engines are performed according to the current state of the event. In some embodiments, in addition to the state data and other identification data, the record generated by the stateless application module for the event also includes a version number. The version number may be initiated with an initial version number when the record is created. When an instance of the stateless application module updates the state data of the record, the instance of the stateless application module may also update the version number (e.g., by incrementally increasing the version number, etc.).

In some embodiments, when the first instance of the stateless application module transmits the job request to a data processing engine, the first instance of the stateless application module may include in the job request the version number as well as the state data of the record. The response from the data processing engine may also include the state data and the version number. Upon receiving the response and before updating the state data in the record, the second instance of the stateless application module may check the version number stored in the record against the version number indicated in the response. If the version numbers match, the stateless application module may proceed with updating the state data in the record based on the response. On the other hand, if the version number in the record and the version number indicated in the response do not match, the stateless application module may retrieve the updated state data from the record and transmit another job request to the data processing engine with the updated state data, such that the data processing engine may perform the data processing based on the updated state data.

In some embodiments, the context database may also verify the version number before allowing the stateless application module to update the state data. For example, when the second instance of the stateless application module requests to update the state data of a record, the second instance of the stateless application module may also provide a version number. The context database may compare the version number received from the stateless application module against the version number currently stored in the record. If the context database determines that the version number received from the stateless application module and the version number currently stored in the record match, the context database may allow the second instance of the stateless application module to update the state data. However, if the context database determines that the version number received from the stateless application module and the version number currently stored in the record do not match, the context database may prohibit the second instance of the stateless application module from updating the state data. Such operations can ensure consistency of data and prevent one instance of a stateless application from performing an update that would conflict with another update from a different instance.

illustrates an electronic transaction systemaccording to one embodiment of the disclosure in which a stateless application framework may be implemented. The electronic transaction systemincludes a service provider server, a merchant server, and a user devicethat may be communicatively coupled with each other via a network. The network, in one embodiment, may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, the networkmay include the Internet and/or one or more intranets, landline networks, wireless networks, and/or other appropriate types of communication networks. In another example, the networkmay comprise a wireless telecommunications network (e.g., cellular phone network) adapted to communicate with other communication networks, such as the Internet.

The user device, in one embodiment, may be utilized by a userto interact with the merchant serverand/or the service provider serverover the network. For example, the usermay use the user deviceto log in to a user account to conduct account services or conduct financial transactions (e.g., account transfers or payments) with the service provider server. The usermay also use the user deviceto initiate an event (e.g., requesting for working capital) with the service provider server. Similarly, a merchant associated with the merchant servermay use the merchant serverto log in to a merchant account to conduct account services or conduct financial transactions (e.g., payment transactions) with the service provider server. The merchant may use the merchant serverto initiate an event (e.g., a seller onboarding request) with the service provider server. The user deviceand the merchant server, in various embodiments, may be implemented using any appropriate combination of hardware and/or software configured for wired and/or wireless communication over the network. In various implementations, the user devicemay include at least one of a wireless cellular phone, wearable computing device, PC, laptop, etc.

The user device, in one embodiment, includes a user interface (UI) application(e.g., a web browser), which may be utilized by the userto conduct transactions (e.g., shopping, purchasing, bidding, etc.) or initiate events (e.g., working capital requests, etc.) with the service provider serverover the network. In one aspect, purchase expenses may be directly and/or automatically debited from an account related to the uservia the user interface application.

In one implementation, the user interface applicationincludes a software program, such as a graphical user interface (GUI), executable by a processor that is configured to interface and communicate with the service provider servervia the network. In another implementation, the user interface applicationincludes a browser module that provides a network interface to browse information available over the network. For example, the user interface applicationmay be implemented, in part, as a web browser to view information available over the network.

The user device, in various embodiments, may include other applicationsas may be desired in one or more embodiments of the present disclosure to provide additional features available to the user. In one example, such other applicationsmay include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over the network, and/or various other types of generally known programs and/or software applications. In still other examples, the other applicationsmay interface with the user interface applicationfor improved efficiency and convenience.

The user device, in one embodiment, may include at least one identifier, which may be implemented, for example, as operating system registry entries, cookies associated with the user interface application, identifiers associated with hardware of the user device(e.g., a media control access (MAC) address), or various other appropriate identifiers. The identifiermay include one or more attributes related to the userof the user device, such as personal information related to the user (e.g., one or more user names, passwords, photograph images, biometric IDs, addresses, phone numbers, social security number, etc.) and banking information and/or funding sources (e.g., one or more banking institutions, credit card issuers, user account numbers, security data and information, etc.). In various implementations, the identifiermay be passed with a user login request to the service provider servervia the network, and the identifiermay be used by the service provider serverto associate the user with a particular user account maintained by the service provider server.

In various implementations, the useris able to input data and information into an input component (e.g., a keyboard) of the user deviceto provide user information with a transaction request, such as a login request, a fund transfer request, a request for adding an additional funding source (e.g., a new credit card), or other types of request. The user information may include user identification information.

The user device, in various embodiments, includes a location componentconfigured to determine, track, monitor, and/or provide an instant geographical location of the user device. In one implementation, the geographical location may include GPS coordinates, zip-code information, area-code information, street address information, and/or various other generally known types of location information. In one example, the location information may be directly entered into the user deviceby the user via a user input component, such as a keyboard, touch display, and/or voice recognition microphone. In another example, the location information may be automatically obtained and/or provided by the user devicevia an internal or external monitoring component that utilizes a global positioning system (GPS), which uses satellite-based positioning, and/or assisted GPS (A-GPS), which uses cell tower information to improve reliability and accuracy of GPS-based positioning. In other embodiments, the location information may be automatically obtained without the use of GPS. In some instances, cell signals or wireless signals are used. For example, location information may be obtained by checking in using the user devicevia a check-in device at a location, such as a beacon. This helps to save battery life and to allow for better indoor location where GPS typically does not work.

Even though only one user deviceis shown in, it has been contemplated that one or more user devices (each similar to user device) may be communicatively coupled with the service provider servervia the networkwithin the system.

The merchant server, in various embodiments, may be maintained by a business entity (or in some cases, by a partner of a business entity that processes transactions on behalf of business entity). Examples of business entities include merchant sites, resource information sites, utility sites, real estate management sites, social networking sites, etc., which offer various items for purchase and process payments for the purchases. The merchant servermay include a merchant databasefor identifying available items, which may be made available to the user devicefor viewing and purchase by the user.

The merchant server, in one embodiment, may include a marketplace application, which may be configured to provide information over the networkto the user interface applicationof the user device. For example, the userof the user devicemay interact with the marketplace applicationthrough the user interface applicationover the networkto search and view various items available for purchase in the merchant database.

The merchant server, in one embodiment, may include at least one merchant identifier, which may be included as part of the one or more items made available for purchase so that, e.g., particular items are associated with the particular merchants. In one implementation, the merchant identifiermay include one or more attributes and/or parameters related to the merchant, such as business and banking information. The merchant identifiermay include attributes related to the merchant server, such as identification information (e.g., a serial number, a location address, GPS coordinates, a network identification number, etc.).

A merchant may also use the merchant serverto communicate with the service provider serverover the network. For example, the merchant may use the merchant serverto communicate with the service provider serverin the course of various services offered by the service provider to a merchant, such as seller onboarding, payment intermediary between customers of the merchant and the merchant itself. For example, once the merchant has successfully completed the seller onboarding process with the service provider server to become an authorized seller, the merchant servermay use an application programming interface (API) that allows it to offer sale of goods or services in which customers are allowed to make payment through the service provider server, while the usermay have an account with the service provider serverthat allows the userto use the service provider serverfor making payments to merchants that allow use of authentication, authorization, and payment services of the service provider as a payment intermediary. The merchant may also have an account with the service provider server. Even though only one merchant serveris shown in, it has been contemplated that one or more merchant servers (each similar to merchant server) may be communicatively coupled with the service provider serverand the user devicevia the networkin the system.

The service provider server, in one embodiment, may be maintained by a transaction processing entity or an online service provider, which may provide processing for electronic transactions between the userof the user deviceand one or more merchants. As such, the service provider servermay include one or more service applications, which may be adapted to interact with the user deviceand/or the merchant serverover the networkto facilitate the seller onboarding, working capital requests, data transfers, content access, searching, selection, purchase, payment of items, and/or other services offered by the service provider server. In one example, the service provider servermay be provided by PayPal®, Inc. of San Jose, Calif., USA, and/or one or more service entities or a respective intermediary that may provide multiple point of sale devices at various locations to facilitate transaction routings between merchants and, for example, service entities.

In some embodiments, the service applicationmay include a payment processing application (not shown) for processing purchases and/or payments for electronic transactions between a user and a merchant or between any two entities. In one implementation, the payment processing application assists with resolving electronic transactions through validation, delivery, and settlement. As such, the payment processing application settles indebtedness between a user and a merchant, wherein accounts may be directly and/or automatically debited and/or credited of monetary funds in a manner as accepted by the banking industry.

The service provider servermay also include a web serverthat is configured to serve web content to users in response to HTTP requests. As such, the web servermay include pre-generated web content ready to be served to users. For example, the web servermay store a log-in page, and is configured to serve the log-in page to users for logging into user accounts of the users to access various service provided by the service provider server. The web servermay also include other webpages associated with the different services offered by the service provider server, such as a webpage that enables a user to initiate a working capital request and a webpage that enables a user to initiate a seller onboarding process. As a result, a user may access a user account associated with the user and access various services offered by the service provider server, by generating HTTP requests directed at the service provider server.

The service provider servermay also include a stateless application frameworkthat provides the components to implement one or more stateless applications. For example, one or more of the service applicationsmay be implemented within the stateless application frameworkto improve the efficiency and performance of the service applications, such as improving the speed of processing data by the service applicationsand reducing computational resources required by the service applications. Note that the stateless application frameworkis not limited to web server contexts but may be used in a number of various computing contexts.

The service provider server, in one embodiment, may be configured to maintain one or more user accounts and merchant accounts in an account database, each of which may include account information associated with one or more individual users (e.g., the userassociated with user device) and merchants. For example, account information may include private financial information of users and merchants, such as one or more account numbers, passwords, credit card information, banking information, digital wallets used, or other types of financial information, transaction history, Internet Protocol (IP) addresses, device information associated with the user account, which may be used by the web serverto determine whether to authorize or deny a request associated with the user account. In certain embodiments, account information also includes user purchase profile information such as account funding options and payment options associated with the user, payment information, receipts, and other information collected in response to completed funding and/or payment transactions.

User purchase profile information may be compiled or determined in any suitable way. In some instances, some information is solicited when a user first registers with a service provider. The information might include demographic information, a survey of purchase interests, and/or a survey of past purchases. In other instances, information may be obtained from other databases. In certain instances, information about the user and products purchased are collected as the user shops and purchases various items.

In one implementation, a user may have identity attributes stored with the service provider server, and the user may have credentials to authenticate or verify identity with the service provider server. User attributes may include personal information, banking information and/or funding sources. In various aspects, the user attributes may be passed to the service provider serveras part of a login, search, selection, purchase, and/or payment request, and the user attributes may be utilized by the service provider serverto associate the user with one or more particular user accounts maintained by the service provider server.

illustrates a block diagram of the stateless application frameworkaccording to an embodiment of the disclosure. The stateless application frameworkincludes a stateless application module, a context database, and a messaging queue (a messaging module)in this embodiment. As shown, the stateless application moduleis communicatively coupled to one or more applications (e.g., one or more service applications). In this example, the stateless application moduleis communicatively coupled to an onboarding application, a working capital application, and a negative balance application. Each of the applications-may be configured to perform a process according to a workflow using one or more of the data processing engines-via the stateless application framework. For example, the onboarding applicationmay be configured to, in response to receiving an onboarding request from a merchant via the merchant serveror from the uservia the user device, perform an onboarding process according to a corresponding onboarding workflow to authorize the merchant or the user to become an authorized user for using electronic services that the service provider serveroffers to authorized users. In some embodiments, the process (e.g., the user onboarding process) and the corresponding workflow may define a state machine configuration that includes multiple states and available paths to traverse the states. Each of applications,, andmay be internally stateless—that is, they may be configured to take a particular action in response to particular input, but do not store internal state that would affect the action taken; rather, only the input (which may include state information) dictates the action(s) taken, according to various embodiments.

illustrates an example state machine configurationaccording to an embodiment of the disclosure. As shown, the state machine configurationincludes five different states-and various paths to traverse among the different states-. Each of the states-may indicate a progress within the corresponding workflow, and may also indicate to the corresponding application a status of an associated user account. For example, the state machine configurationmay correspond to the onboarding application configured to perform an onboarding process to approve a user account to become an authorized user for the service provider server. In this example, each of the different states-may indicate a different approval status within the onboarding workflow. For example, the statemay be a start state of the onboarding workflow and may indicate that the onboarding process has just begun. As such, the user account may be assigned to the statewhen the onboarding process begins.

The statemay be an intermediate state and may indicate that the user account is partially approved. For example, the statemay indicate that at least one of the sub-processes of the onboarding process is completed. As shown, from the state, the user account may reach the state, for example, based on a completion of a sub-process or an indication of an event. In one example, one or more of the data processing engines-may be used to process data associated with the user account. Based on a completion of the sub-process by one or more of the data processing engine-, the user account may be moved from the stateto the state.

From the state, the user account may reach either the stateor the state. The statemay be another intermediate state and may indicate a pending state of a particular sub-process of the onboarding process, while the statemay be a complete approval state indicating that the user account is fully approved to be an authorized user. For example, when the user account is at the state, based on one or more criteria using data associated with the user account, the onboarding workflow may require that a background check to be performed on the user account. In one example, one of more data processing engines-may be used to analyze the data associated with the user account to determine whether a background check is required. In the event that the background check is not required, the user account may reach the statefrom the state, indicating that the user account is fully approved to be an authorized user for the service provider server. On the other hand, if it is determined that a background check is required to be performed on the user account, the user account may reach the statewhile awaiting a result of the background check, which may take an extended period of time (e.g., hours or days) to complete.

From the state, the user account may reach the stateor the state, depending on the result from the background check. For example, if it is determined that the background check is clear, the user account may be moved to the complete approval state. On the other hand, if it is determined that the background check has failed, the user account may be moved to the state, which may be a denied state indicating that the onboarding request of user account is denied.

As shown in this example, even when the user account is in the denied state, the state machine configurationmay allow the user account to traverse back to the statebased on an event. For example, the onboarding process may allow the user account to reapply to be an authorized user when a predetermined time period (a month, a year, etc.) has passed or a specific event has occurred (e.g., payment of a debt, increase of a credit score above a threshold, increase of income above a threshold, etc.) after the user account has been denied. The user account is then moved to the state. As such, the state machine configurationmay provide traversal among the different states-based on a completion of one or more predetermined sub-processes or an indication of an event. While the state machine configurationwas discussed using the example of an onboarding application, it has been contemplated that the state machine configuration(or another state machine configuration) may be used for other applications, such as the working capital applicationor the negative balance application. As such, multiple state machine configurations (e.g., state machine configurationsa,b, andc) corresponding to different applications may be stored by the stateless application module, for example, in the context database.

illustrates a processfor providing a stateless application framework to facilitate the processes/workflows associated with various applications according to various embodiments of the disclosure. In some embodiments, the processmay be performed by the stateless application framework(and the stateless application module) of the service provider server. As discussed above, the stateless application frameworkmay be configured to facilitate processing of data for various applications. The stateless application frameworkmay be provided as a service to the various applications to facilitate processing of data using the stateless application module. For example, the stateless application frameworkmay be implemented to include a software library and a set of application programming interfaces (APIs) to interface with the applications.

In some embodiments, an application may configure the stateless application frameworkto facilitate data processing for the application by providing one or more state machine configurations and one or more workflows (e.g., via the set of APIs). For example, a state machine configurationa may be obtained by the stateless application moduleto be associated with the onboarding application, a state machine configurationb may be obtained by the stateless application moduleto be associated with the working capital application, and a state machine configurationc may be obtained by the stateless application moduleto be associated with the negative balance application.

In addition, each of the workflows provided by an application may include performing one or more actions using one or more of the data processing engines-. Each workflow may be implemented as a data file, such as an XML file, and may indicate performance of one or more actions. At least some of the actions indicated in the workflow may be dependent on a status of the user account. For example, the workflow may indicate a performance of a first task if the user account is at stateand a performance of a second task if the user account is at state.

The processmay begin by receiving (at step) an indication of an event. For example, an indication of an event may be received from one of the applications-(e.g., via an API call). In one example, the indication may be an onboarding event for a user account received from the onboarding application. Upon receiving the indication, an instance of the stateless application modulemay be instantiated (e.g., by a computer system on which the stateless application moduleruns) to perform functionalities based on the indication. In some embodiments, the instance of the stateless application modulemay be a new process or a new thread, to which certain computer resources (e.g., non-persistent memory space, processing cycles, etc.) may be allocated by the computer system that implements the stateless application module. For clarity and simplicity, the instance of the stateless application modulemay be referred simply as the stateless application module.

Multiple instances of the stateless application modulemay be instantiated and concurrently running within the stateless application framework. For example, if another indication is received (e.g., from the working capital application), another instance of the stateless application modulemay be instantiated for performing functionalities for the working capital application.

Based on the indication and the application from which the indication is received, the processmay select (at step) a state machine configuration and a workflow corresponding to the event. For example, the stateless application modulemay determine that the indication is received from the onboarding application, and may select and retrieve the state machine configurationa and the workflow corresponding to the onboarding applicationfrom the context database. In some embodiments, the state machine configurationa may correspond to the state machine configurationof. In some embodiments, instead of using the workflow stored in the database, the stateless application modulemay enable the applications to specify a customized workflow for the event. For example, the onboarding application may include in the indication a customized workflow specific to the user account. While the customized workflow still corresponds to the state machine configurationa, the customized workflow may specify different processing configurations than the workflow stored in the database. For example, the customized workflow may require that certain sub-processes of the onboarding process to be performed in serial, instead of in parallel as required by the workflow stored in the database, and vice versa.

The stateless application modulemay assign a state in the state machine configuration to the event based on the workflow, and store the state data associated with the event in a persistent data storage (e.g., a hard drive, a flash drive, etc.). As such, the processthen creates (at step) a record and stores the record in a persistent storage for the event. For example, since the stateless application modulehas just received the indication of the event without performing any processing according to the workflow, the user account (and/or the event) is assigned to the start state (e.g., the stateof the state machine configuration). As such, the stateless application modulemay generate a record for the event and/or the user account, and may insert state data indicating the start statein the record. The stateless application modulemay also store the record in the context database.

In some embodiments, the context databasemay include data structures and modules for managing data in the data structures (e.g., a relationship database management system, etc.). The data and the data structures may be stored in non-persistent data storage (e.g., a hard drive, a flash drive, etc.). Furthermore, the context databasemay be external to the stateless application modulesuch that the records stored in the context databasemay still be made available when instances of the stateless application module are terminated and/or the stateless application framework is shut down (or crashes).

In order to ensure consistency of services delivered by the data processing engines-, the stateless application modulemay also include a version number indicating a version of the state data in the record. When the record is created, an initial version number (e.g., 1.0) may be assigned to, and stored in, the record.

After creating the record, the stateless application modulemay begin performing functionalities for the event. For example, the stateless application modulemay begin performing tasks according to the workflow associated with the event (either retrieved from the database or provided in the indication). In some embodiments, the tasks may be delegated by the stateless application moduleto one or more of the data processing engine-according to the workflow. As such, the workflow may indicate which of the data processing engines-to use to perform the tasks. In some of these embodiments, the workflow may also indicate an order of calling the different data process engines-to performing the tasks. For example, the workflow may indicate calling the data processing enginesandin parallel (as the tasks performed by the data processing engineanddo not depend on each other), but calling the data processing engineonly after the tasks performed by the data processing engineis completed. Furthermore, the workflow may indicate which of the data processing engines-to use based on the state of the user account. For example, the workflow may indicate calling the data processing engines,, andwhen the user account is in state, and calling the data processing enginesandwhen the user account is in state.