Description:FIELD OF INVENTION
[0001] The embodiments of the present disclosure generally relate to transactional flows in online booking platforms and e-commerce environment. More particularly, the present disclosure relates to a system and a method for managing transactional states in a workflow orchestration.

BACKGROUND
[0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section be used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.
[0003] Generally, electronic commerce (e-commerce) has been predominating in the market for decades to purchase goods. Consumers may be able to browse a variety of products online, shop according to their preferences, and check discounts for the products to purchase. When a user is ready to purchase the products, the user indicates that by including the products in the user’s shopping cart and arranges for payment for the products. Further, in some instances, the user might not complete the transaction i.e. execution of checkout due to various reasons such as, but not limited to, awaiting a better deal, early delivery, looking out for discounts, and so on. Such instances may lead to incomplete execution of the workflow.
[0004] In a typical distributed transactional scenario, this complexity is handled via saga pattern (choreography based/orchestrator based) where the crux of the solution is built on event propagation i.e. asynchronous way of communication. However, there are other limitations as well with respect to saga patterns. The typical distributed transactions implement synchronous states with write systems in case of any failure by doing a read repair (i.e. querying respective systems).
[0005] Therefore, there is a need for a system and a method for solving the shortcomings of the conventional methods.

SUMMARY
[0006] This section is provided to introduce certain objects and aspects of the present invention in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter. In order to overcome at least a few problems associated with the known solutions as provided in the previous section, an object of the present disclosure is to provide a technique that may be for managing transactional states in a workflow orchestration.
[0007] It is an object of the present disclosure to provide a system and a method for managing transactional states in a workflow orchestration in an e-commerce environment and travel/services booking environment.
[0008] It is another object of the present disclosure to provide a system and a method for handling dependency of multiple transactional states in a generic fashion to drive the workflow either in a forward direction or backward direction, i.e. rollback.
[0009] It is yet another object of the present disclosure to provide a system and a method for enabling changes in multiple states of one or more transactions seamlessly.
[0010] It is yet another object of the present disclosure to provide a system and a method for representing subdomain dependency and cardinality relationship of one or more transactional states in a simple manner.
[0011] It is another object of the present disclosure to provide a system and a method enabling an order management system to interact with fulfillment and accounting in an effective way.
[0012] It is yet another object of the present disclosure to provide a system and a method for facilitating backend payment which needs to interact with multiple payment gateway and wallets for a single transaction.
[0013] It is yet another object of the present disclosure to provide a system and a method for enabling real-time and robust techniques to execute checkout mechanisms by dealing with multiple systems like inventory, payments, and order management systems.
[0014] In an aspect, the present disclosure provides a system for managing transactional states in a workflow orchestration. The system may be configured to receive one or more data packets including a user request, where the user request may pertain to one or more transactions. Further, the system may be configured to manage at least one resource and a corresponding transactional state of the one or more transactions in real-time. The transactional state may include at least one of a commit state, an abort state, and a rollback state. Furthermore, the system may be configured to perform a distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status. Finally, the system may be configured to maintain at least one local proxy state in the distributed form of the one or more transactions based on one or more conditions and the one or more mapping status, and achieve the transactional state of the one or more transactions in the synchronous mode in a workflow orchestration.
[0015] In an embodiment, the one or more conditions may include at least one of a reversal flow, a fault detection, a failure occurrence, and a delay period.
[0016] In an embodiment, the one or more mapping status may include at least one of a transaction system to identity (ID) mapping and an ID to transaction state mapping. The transaction system to ID mapping may pertain to one or more subdomains and corresponding identities along with relationship state, where the one or more subdomains may include at least one of an inventory, a payment, and a checkout. Further, the ID to state mapping may pertain to a current state and corresponding identities of the one or more subdomains, where the current state may include at least one of an active state, a pending state, and a terminated state.
[0017] In an embodiment, the system may be configured to handle dependency of the one or more subdomains based on the transactional state to execute the workflow orchestration.
[0018] In an embodiment, the system may be configured to perform a checkout to regulate the one or more subdomains including at least one of the inventory, the payment, and an order management. Further, the system may be configured to enable a prepare command locally in a workflow orchestrator, followed by a Remote Procedure Call (RPC), and execution of the transactional state locally based on a response of the RPC.
[0019] In an embodiment, the system may include a persistent layer configured to store the one or more mapping status of a closest subdomain in the distributed form, and access the transactional state across one or more Application Programming Interface (API) calls for enabling execution of the workflow orchestration.
[0020] In another embodiment, the system may include a caching layer coupled to the persistent layer, and configured to store the one or more mapping status to authorize access of the one or more mapping status multiple times as part of the execution of the workflow orchestration.
[0021] In another embodiment, the system may include an API layer configured to provide recommendations to fetch the one or more mapping status from at least one of the persistent layer and the caching layer, where the API layer may include at least one of a transactional API and a utility API.
[0022] In yet another embodiment, the system may be configured to handle one or more concurrent calls by implementing a semantic lock mechanism in a database layer and update content in records of the database layer.
[0023] In another aspect, the present disclosure provides a method for managing transactional states in a workflow orchestration. The method may include receiving, by a system, one or more data packets including a user request, where the user request may pertain to one or more transactions. Further, the method may include managing, by the system, at least one resource and corresponding transactional state of the one or more transactions in real-time, where the transactional state may include at least one of a commit state, an abort state, and a rollback state. Furthermore, the method may include performing, by the system, a distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status. Finally, the method may include maintaining, by the system, at least one local proxy state in distributed form of the one or more transactions based on one or more conditions and the one or more mapping status, and achieve the transactional state of the one or more transactions in the synchronous mode in the workflow orchestration.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS
[0024] The accompanying drawings, which are incorporated herein, and constitute a part of this invention, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry/sub-components of each component. It will be appreciated by those skilled in the art that the invention of such drawings includes the invention of electrical components, electronic components, or circuitry commonly used to implement such components.
[0025] FIG. 1 illustrates an exemplary representation of a network architecture for implementing a proposed system for managing transactional states in a workflow orchestration, according to embodiments of the present disclosure.
[0026] FIG. 2 illustrates an exemplary block diagram representation of the proposed system, according to embodiments of the present disclosure.
[0027] FIGs. 3A-3C illustrate exemplary representations of different functionalities of the proposed system for managing transactional states in a workflow orchestration, according to embodiments of the present disclosure.
[0028] FIGs. 4A-4C illustrate exemplary representations for managing transactional states in a workflow orchestration handling concurrent calls, according to embodiments of the present disclosure.
[0029] FIG. 5 illustrates an exemplary flow diagram for managing transactional states in a workflow orchestration handling concurrent calls, according to embodiments of the present disclosure.
[0030] FIGs. 6A-6B illustrate exemplary sequence flow diagrams for managing transactional states in a workflow orchestration handling concurrent calls, according to embodiments of the present disclosure.
[0031] FIG. 7 illustrates an exemplary flow chart of a method for managing transactional states in a workflow orchestration, according to embodiments of the present disclosure.
[0032] FIG. 8 illustrates an exemplary hardware platform for implementing the disclosed system, according to embodiments of the present disclosure.
[0033] The foregoing shall be more apparent from the following more detailed description of the invention.

DETAILED DESCRIPTION OF INVENTION
[0034] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0035] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that, various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth.
[0036] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0037] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0038] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0039] As used herein, “connect,” “configure,” “couple,” and its cognate terms, such as “connects,” “connected,” “configured,” and “coupled” may include a physical connection (such as a wired/wireless connection), a logical connection (such as through logical gates of semiconducting device), other suitable connections, or a combination of such connections, as may be obvious to a skilled person.
[0040] As used herein, “send,” “transfer,” “transmit,” and their cognate terms like “sending,” “sent,” “transferring,” “transmitting,” “transferred,” “transmitted,” etc. include sending or transporting data or information from one unit or component to another unit or component, wherein the content may or may not be modified before or after sending, transferring, transmitting.
[0041] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0042] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed products.
[0043] Various embodiments of the present disclosure provide a system and a method managing transactional states in a workflow orchestration in an e-commerce environment and travel/services booking environment. The present disclosure provides a system and a method for handling the dependency of multiple transactional states in a generic fashion to drive the workflow either in a forward direction or a backward direction, i.e. rollback. The present disclosure provides a system and a method for enabling changes in multiple states of one or more transactions seamlessly. The present disclosure provides a system and a method for representing subdomain dependency and cardinality relationship of the one or more transactional states in a simple manner. The present disclosure provides a system and a method by enabling an order management system to effectively interact with fulfillment and accounting modules. The present disclosure provides a system and a method for facilitating backend payment which needs to interact with multiple payment gateway and wallets for a single transaction. The present disclosure provides a system and a method for enabling real-time and robust techniques to execute the checkout mechanism by dealing with multiple systems like inventory, payments, and order management systems.
[0044] Various embodiments throughout the disclosure will be explained with reference to FIGs. 1-8.
[0045] FIG. 1 illustrates an exemplary representation of a network architecture 100 for implementing a proposed system for managing transactional states in a workflow orchestration, according to embodiments of the present disclosure.
[0046] Referring to FIG. 1, the network architecture 100 may include the system 110, an electronic device 108, and a centralized server 118. The system 110 (also known as transactional system or transactional manager herein) may be connected to the centralized server 118 via a communication network 106.
[0047] In an embodiment, the centralized server 118 may include, but is not limited to, a stand-alone server, a remote server, a cloud computing server, a dedicated server, a rack server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof, and the like. In an embodiment, the centralized server 118 may be associated with an entity corresponding to an electronic commerce (e-commerce) environment and/or travel/services booking environment.
[0048] In an embodiment, the communication network 106 may be a wired communication network or a wireless communication network. The wireless communication network may be any wireless communication network capable of transferring data between entities of that network such as, but is not limited to, a Bluetooth, a Zigbee, a Near Field Communication (NFC), a Wireless-Fidelity (Wi-Fi), a Light Fidelity (Li-FI), a carrier network including a circuit-switched network, a public switched network, a Content Delivery Network (CDN) network, a Long-Term Evolution (LTE) network, a New Radio (NR), a Narrow-Band (NB), an Internet of Things (IoT) network, a Global System for Mobile Communications (GSM) network and a Universal Mobile Telecommunications System (UMTS) network, an Internet, intranets, Local Area Networks (LANs), Wide Area Networks (WANs), mobile communication networks, combinations thereof, and the like.
[0049] Referring to FIG. 1, the system 110 may be implemented by way of a single device or a combination of multiple devices that may be operatively connected or networked together. For example, the system 110 may be implemented by way of a standalone device and may be communicatively coupled to the electronic device 108. In another example, the system 110 may be implemented in/associated with the electronic device 108. In yet another example, the system 110 may be implemented in/associated with respective computing devices (104-1, 104-2…104-N) associated with one or more users (102-1, 102-2…102-N). A person of ordinary skill in the art will understand that the one or more computing devices (104-1, 104-2…104-N) may be collectively referred as the computing devices 104 and individually referred as the computing device 104. Similarly, the one or more users (102-1, 102-2…102-N) may be collectively referred as the users 102 and individually referred as the user 102. In such a scenario, the system 110 may be replicated in each of the computing devices 104.
[0050] In an embodiment, the user 102 may be a user of, but not limited to, an electronic commerce (e-commerce) platform, a hyperlocal platform, a super-mart platform, a media platform, a service providing platform, a social networking platform, a travel/services booking platform, a messaging platform, a bot processing platform, a virtual assistance platform, an Artificial Intelligence (AI) based platform, a blockchain platform, a blockchain marketplace, and the like. In some embodiments, the user 102 may correspond to an entity/administrator of platforms/services.
[0051] In an embodiment, the electronic device 108 and/or the computing device 104 may include, but not be limited to, an electrical, an electronic, an electromechanical, and a computing device. The electronic device 108 and/or the computing device 104 may include, but not limited to, a mobile device, a smart-phone, a Personal Digital Assistant (PDA), a tablet computer, a phablet computer, a wearable computing device, a Virtual Reality/Augmented Reality (VR/AR) device, a laptop, a desktop, a server, and the like.
[0052] In an embodiment, the system 110 may be implemented in hardware or a suitable combination of hardware and software. The system 110 or the centralized server 118 may be associated with entities (not shown). The entities may include, but are not limited to, an e-commerce company, a travel company, an airline company, a hotel booking company, a company, an outlet, a manufacturing unit, an enterprise, a facility, an organization, an educational institution, a secured facility, a warehouse facility, a supply chain facility, and the like.
[0053] Referring to FIG. 1, the system 110 may include a processor 112, an Input/Output (I/O) interface 114, and a memory 116. The I/O interface 114 may be used to receive inputs from the computing devices 104 associated with the users 102. Further, system 110 may also include other units such as a display unit, an input unit, an output unit, and the like, however the same are not shown in FIG. 1, for the purpose of clarity. Also, in FIG. 1 only a few units are shown, however, the system 110 or the network architecture 100 may include multiple such units or the system 110/network architecture 100 may include any such numbers of the units, obvious to a person skilled in the art or as required to implement the features of the present disclosure.
[0054] In an embodiment, the system 110 may be a hardware device including the processor 112 executing machine-readable program instructions to execute workflow orchestration. Execution of the machine-readable program instructions by the processor 112 may enable the proposed system 110 to execute workflow orchestration. The “hardware” may comprise a combination of discrete components, an integrated circuit, an application-specific integrated circuit, a field-programmable gate array, a digital signal processor, or other suitable hardware. The “software” may comprise one or more objects, agents, threads, lines of code, subroutines, separate software applications, two or more lines of code, or other suitable software structures operating in one or more software applications or on one or more processors. The processor 112 may include, for example, but is not limited to, microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and any devices that manipulate data or signals based on operational instructions, and the like. Among other capabilities, the processor 112 may fetch and execute computer-readable instructions in the memory 116 operationally coupled with the system 110 for performing tasks such as data processing, input/output processing, feature extraction, and/or any other functions. Any reference to a task in the present disclosure may refer to an operation being or that may be performed on data.
[0055] In the example that follows, assume that a user 102 of the system 110 desires to purchase one or more products in an e-commerce environment. The system 110 may be configured to manage transactional states in the workflow orchestration by adapting a distributed coordination. The system 110 may be configured to use all resources or release all resources and the operations may happen in synchronization. Further, bookkeeping of the transactional states may be necessary for bringing determinism into state machine execution. The system 110 may have different consistency guarantees to meet business needs. For example, in few cases, reversal flow (i.e. undo of the state change) needs to be kicked in as soon as anomaly/failure is encountered while the same constraint can also be relaxed for other systems.
[0056] In an embodiment, the system 110 may be configured to implement the distributed coordination by maintaining a local state/proxy and provide necessary hooks to prepare/commit/rollback as and when required, specifically, as part of a complex workflow execution (like e-commerce world transactional flow) which deals with write transactions. The system 110 facilitates the state change of multiple transactional systems in live flow, and deal with the valuable resources which need to be returned to the pool if not used. In this instance, the user 102 may include an administrator of a website, an administrator of an e-commerce site, an administrator of a social media site, an administrator of an e-commerce application/social media application/other applications, an administrator of media content (e.g., television content, video-on-demand content, online video content, graphical content, image content, augmented/virtual reality content, metaverse content), an administrator of supply chain platform, an administrator of blockchain marketplace, an administrator of a travel/services booking platform, among other examples.
[0057] In an embodiment, the system 110 may receive one or more data packets comprising a user request, where the user request pertains to one or more transactions. The data packets may include, but not be limited to, a huge file, a single data block, a set of instructions, and the like. The one or more transactions may include, but not be limited to, purchasing goods, booking flight tickets, reserving table at a restaurant, and the like.
[0058] In an embodiment, the system 110 may be configured to manage at least one resource and corresponding transactional state of the one or more transactions in real-time, where the transactional state comprises at least one of a commit state, an abort state, and a rollback state. The at least one resource pertains to availability of the requested resource in the e-commerce environment for completing the one or more transactions. In an embodiment, when the one or more transactions are successful i.e. appropriate resource allocation occurs, then the commit state is applied. When the one or more transactions are unsuccessful i.e. inappropriate resource allocation occurs, then the aborted state is applied. Further, when the one or more transactions are incorrectly executed i.e. incorrect resource allocation occurs, then the rollback state is applied.
[0059] In an embodiment, the system 110 may receive a request to book flight tickets from the user 102. The requested resource in this scenario would be the flight name, destination, customer class, seats, and so on. Upon successful booking transaction, the system 110 may provide appropriate resource allocation to enable the commit state. In another embodiment, the system 110 may receive a request to purchase a laptop in an e-commerce website from the user 102. The requested resource in this scenario would be the brand, configuration, color, and so on. The user 102 may not select the laptop and/or complete the transaction. Upon unsuccessful transaction, the system 110 may provide inappropriate resource allocation to enable the abort state.
[0060] In another embodiment, the system 110 may be configured to perform a distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status. In an embodiment, the one or more mapping status comprises a transaction system to identity (ID) mapping and an ID to transaction state mapping. The transaction system to ID mapping pertains to one or more sub domains and corresponding identities along with relationship state, where the one or more sub domains comprise at least one of an inventory, a payment, and a checkout. Further, the ID to transaction state mapping pertains to a current state and corresponding identities of the one or more sub domains, where the current state comprises at least one of an active state, a pending state, and a terminated state.
[0061] In an embodiment, the system 110 may be configured to handle dependency of the one or more sub domains based on the transactional state to execute the workflow orchestration. Further, the system 110 may be configured to perform a checkout to regulate the one or more sub domains comprising at least one of the inventory, the payment, and an order management. A prepare command is enabled locally in the workflow orchestrator, followed by a Remote Procedure Call (RPC) and execution of the transactional state locally based on a response of the RPC.
[0062] In another embodiment, the system 110 may be configured to maintain at least one local proxy state in distributed form of the one or more transactions based on one or more conditions and the one or more mapping status, and achieve the transactional state of the one or more transactions in the synchronous mode in the workflow orchestration. The one or more conditions comprise at least one of a reversal flow, a fault detection, a failure occurrence, and a delay period.
[0063] In an embodiment, an Application Programming Interface (API) layer may be configured to provide recommendations to fetch the one or more mapping status from at least one of a persistent layer and a caching layer. The API layer comprises at least one of a transactional API and a utility API. The persistent layer may be configured to store the one or more mapping status of a closest sub domain in the distributed form, and access the transactional state across one or more API calls for enabling the workflow execution. The caching layer may be coupled to the persistent layer, and configured to store the one or more mapping status to authorize access of the one or more mapping status multiple times as part of the workflow execution.
[0064] In an embodiment, the system 110 may be configured to handle one or more concurrent calls by implementing a semantic lock mechanism in a database layer and update content in records of the database layer.
[0065] FIG. 2 illustrates an exemplary block diagram of the proposed system 110, according to embodiments of the present disclosure.
[0066] Referring to FIG. 2, the system 110 may include the processor 112, the I/O interface 114, and the memory 116. In some implementations, the system 110 may include data 202 and modules 204. As an example, the data 202 may be stored in the memory 116 configured in the system 110 as shown in FIG. 2.
[0067] In an embodiment, the data 202 may include a transactional state data 206, a local proxy state data 208, a mapping status data 210, an order management data 212, a payment data 214, an inventory data 216, and other data 218. In an embodiment, the data 202 may be stored in the memory 116 in the form of various data structures. Additionally, the data 202 may be organized using data models, such as relational or hierarchical data models. The other data 218 may store data including temporary data and temporary files, generated by the modules 204, for performing various functions of the system 110.
[0068] In an embodiment, the modules 204 may include a receiving module 220, a managing module 222, a transmitting module 224, and other modules 226.
[0069] In an embodiment, the data 202 stored in the memory 116 may be processed by the modules 204 of the system 110. In an embodiment, the modules 204 may be stored within the memory 116. In an example, the modules 204 communicatively coupled to the processor 112 configured in the system 110 may also be present outside the memory 116, as shown in FIG. 2, and implemented as hardware. As used herein, the term modules may refer to an Application-Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.
[0070] In an embodiment, the receiving module 220 may receive one or more data packets comprising a user request, where the user request pertains to one or more transactions. The data packets may include, but not be limited to, a huge file, a single data block, a set of instructions, and the like. The one or more transactions may include, but not be limited to, purchasing goods, booking flight tickets, reserving table at a restaurant, and the like.
[0071] In an embodiment, the managing module 222 may, subject to receipt of the one or more transactions for the product, through a product characterization engine, manage at least one resource and corresponding transactional state of the one or more transactions in real-time. The transactional state comprises at least one of a commit state, an abort state, and a rollback state. The at least one resource pertains to availability of the requested resource in the e-commerce environment for completing the one or more transactions. In an embodiment, when the one or more transactions are successful i.e. appropriate resource allocation occurs, then the commit state is applied. When the one or more transactions are unsuccessful i.e. inappropriate resource allocation occurs, then the aborted state is applied. Further, when the one or more transactions are incorrectly executed i.e. incorrectly resource allocation occurs, then the rollback state is applied.
[0072] In an embodiment, the transmitting module 224 may, upon an affirmative managing, transmit a set of packets to a computing device 104, the set of packets being indicative of confirmed availability of the product by managing transactional states in the workflow orchestration. In an embodiment, upon receipt of the set of packets by the computing device 104, a second set of packets are automatically sent by the computing device 104 to indicate entity’s decision with respect to the product.
[0073] FIGs. 3A-3C illustrate exemplary representations of different functionalities of the proposed system 110 for managing transactional states in a workflow orchestration, according to embodiments of the present disclosure.
[0074] FIG. 3A depicts a workflow orchestration 300 presenting synchronous mode in a two-phase commit protocol (2PC). The workflow orchestration 300 may include the system 110, a checkout block 302 communicatively coupled with an external service 310 via a network 314. The external service 310 is coupled to a database 312. The workflow orchestration 300 has the capability to handle synchronous communication as well as long running one. The basic idea for implementation is to prepare 316 the one or more transactions which occur locally in the orchestrator system. Further, an RPC 318 along with the one or more transactional states such as the commit state 320 are executed locally based on RPC call response. Basically, the closest proxy of each of the subdomain state is stored in orchestrator locally (in distributed fashion) and workflows are driven accordingly.
[0075] FIGs. 3B-3C depict internal data structure for managing transactional states in a workflow orchestration. The system 110 performs the distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status. In an embodiment, the one or more mapping status comprises a transaction system to ID mapping and an ID to transaction state mapping. The transaction system to ID mapping pertains to one or more sub domains and corresponding identities along with relationship state, where the one or more sub domains comprise at least one of an inventory, a payment, and a checkout. Further, the ID to transaction state mapping pertains to a current state and corresponding identities of the one or more sub domains, where the current state comprises at least one of an active state, a pending state, and a terminated state. In an embodiment, the system 110 may be configured to handle dependency of the one or more sub domains based on the transactional state to execute the workflow orchestration. Further, the system 110 may be configured to perform a checkout to regulate the one or more sub domains comprising at least one of the inventory, the payment, and an order management. A prepare command is enabled locally in the workflow orchestrator, followed by an RPC and execution of the transactional state locally based on a response of the RPC.
[0076] In an exemplary embodiment, the transaction system to ID mapping is executed as explained herein. The checkout block 302 may include a list of transactional sub domains i.e. payment 322 and inventory 324 which plays a key role in workflow execution. Further, against each such entity, a list of transaction IDs may be kept which are currently active. Now, depending on the relationship with orchestrator (e.g. checkout 302), this list may have one (1-to-1 relationship) or many (1-to-n relationship) entries. For example, the payment 322 includes a list of commands to be executed such as, but not limited to, create(), capture(), query(), and the like. The inventory 324 includes a list of commands to be executed such as, but not limited to, reserve(), confirm(), unreserve(), and the like.
[0077] In an embodiment, the ID to transaction state mapping may be executed as explained herein. The checkout block 302 holds the current state against each ID irrespective of whether this ID is active or not. Now, this state may be in synchronization with the system 110 (a happy scenario) or it may be a proxy (lagging behind because of retriable failure).
[0078] In an embodiment, the system 110 may be configured to execute the one or more transactions using a pending_inti state 326, an inti state 328, a pending terminate state 330, and a terminate state 332. In an embodiment, the pending_inti state 326 pertains to the one or more transactions in pending state, which may be executed after the previous transaction is completed. The inti state 328 pertains to the one or more transactions being executed. Once the one or more transactions are in execution mode, the pending terminate state 330 may be applied. Finally, the one or more transactions are terminated by using the terminate state 332.
[0079] FIGs. 4A-4C illustrate exemplary architectures of the proposed system 110 for managing transactional states in a workflow orchestration handling concurrent calls, according to embodiments of the present disclosure.
[0080] In an embodiment, the system 110 may be configured to monitor an incorrect way of handling concurrent calls (also known as parallel calls), which is bound to result in inconsistent state. The concurrent calls may lead the system at different points of time with respect to execution timeline of first request. In an embodiment, FIGs. 4A-4C may include the system 110, one or more users (102-1, 102-2), the checkout block 302, and the external service 310. The user (102-1, 102-2) initiates one or more requests (402-1, 402-2) to enable the one or more transactions by using the commands which include, but are not limited to, GET (404-1, 404-2), PUT (406-1, 406-2), pending entry 408, a start transaction 410, an end transaction 412, and so on.
[0081] In an embodiment, FIG. 4A depicts that while the request 402-1 may execute GET 404-1 in the pre() phase of RPC, at that time, another thread/request submits similar command i.e. GET 402-2. This problem have been solved it by supporting cas symantec, where every prepare phase may go via concurrency check at database layer and in worst case both requests may try to update the content and the first one may succeed.
[0082] In an embodiment, FIG. 4B depicts another scenario where successive requests land to the system 110 such as GET 404-1 and GET 402-2, just after the prepare phase of the first request 404-1. In case of concurrent call landing post preparation phase, it will find an entry against ID and behave accordingly. Semantic lock pending entry 408 is a lock that prevents other transactions from accessing the record or a warning that indicates that other transactions should treat that record with suspicion. It is cleared by either a retriable transaction where saga is completing successfully, or by a compensating transaction where the saga is rolling back.
[0083] In an embodiment, FIG. 4C depicts another scenario where solution for idempotency is provided. Being a stateful system, idempotency should be baked into the design which not only helps unnecessary Queries Per Second (QPS) to the database layer but also reduces fan out to external services 310 which internally helps to increase overall throughput. A single RPC call is invoked to the external system 310 instead of two requests landing to the checkout 302. One may define which states in the Finite State Machines (FSM) can be treated as proxy for idempotency. In an embodiment, the user 102-1 initiates the request 402-1 to the checkout 302 and the system receives GET 404-1 request along with start transaction 410. Further, the RPC call is invoked to the external system 310, followed by the end transaction 412 and the response 414-1. Then, the request 402-2 from the user 102-2 is processed.
[0084] FIG. 5 illustrates an exemplary flow diagram 500 for managing transactional states in a workflow orchestration handling concurrent calls, according to embodiments of the present disclosure.
[0085] In an embodiment, FIG. 5 depicts the flow diagram 500 of a proposed system for managing transactional states in a workflow orchestration presenting synchronous mode in a two-phase commit protocol (2PC). The checkout block 302 may include the payment 322 and the inventory 324. First, the user may select one or more products from the e-commerce environment and arrange the list of one or more products i.e. inventory 324. Further, the system 110 may maintain the list of one or more products in the local proxy using a reserve() 324-1. Furthermore, the system 110 may maintain the list of one or more reserved products in the local proxy using a confirm() 324-2. Finally, the one more products are released using unreserve() 324-3 at the time of checkout. When the list of one or more products are not used for a certain period of time, then the system 110 automatically pushes the list of one or more products selected by the user to a resource pool 504. Followed by, the payment 322 has to be initiated by the user during purchase of the list of one or more products, the system 110 maintains the local proxy by using a create() 322-1. Once the payment link has been created and capture() 322-2 the valid information. Further, the query() 322-3 has to be successfully handled by the user to perform checkout 302 and purchase the product 502. When the invalid or error data is inserted by the user, then the system 110 automatically executes exit 506 for the payment 322. The system 110 manages transactional states in a synchronous communication as well as long running one.
[0086] FIGs. 6A-6B illustrate exemplary sequence flow diagrams for managing transactional states in a workflow orchestration handling concurrent calls, according to embodiments of the present disclosure.
[0087] In an embodiment, FIG. 6A depicts a scenario where requests land to the system 110. At step (1), the user 102-1 initiates the REQUEST_USER 1 such as GET(1)_USER 1 at step (2), and PUT(1)_USER 1 AT STEP (3) just after the prepare phase of the first request. In case of concurrent call landing post preparation phase, it will find an entry against ID and behave accordingly. When the user 102-2 initiates the REQUEST_USER 2 such as GET(2)_USER 2 at step (5), semantic lock PENDING_ENTRY AT STEP (6) is automatically provided by the system 110. This is the lock that prevents other transactions from accessing the record or a warning that indicates that other transactions should treat that record with suspicion. It is cleared by either a retriable transaction where saga is completing successfully, or by a compensating transaction where the saga is rolling back.
[0088] In an embodiment, FIG. 6B depicts another scenario where solution for idempotency is provided. At step (1), the user 102-1 initiates the REQUEST_USER 1 such as GET(1)_USER 1 at step (2), and START TRANSACTION_USER 1 at STEP (3) just after the prepare phase of the first request. An RPC is invoked at step (4) to the external service 310. Further, END TRANSACTION_USER 1 at STEP (5) is executed. The user 102-1 receives RESPONSE_USER 1 at step (6) and the transaction is completed. Further, the user 102-2 initiates the REQUEST_USER 2 at step (7) such as GET(2)_USER 2 at step (8), and initiates entry of user 2 at step (9). Finally, the user 102-2 receives RESPONSE_USER 2 at step (10) and the transaction is completed.
[0089] FIG. 7 illustrates a flow chart of a method 700 for managing transactional states in a workflow orchestration, according to embodiments of the present disclosure.
[0090] At block 702, the method 700 includes receiving, by the processor 112 associated with the system 110, one or more data packets comprising a user request, where the user request pertains to one or more transactions.
[0091] At block 704, the method 700 includes managing, by the processor 112, at least one resource and corresponding transactional state of the one or more transactions in real-time, where the transactional state comprises at least one of a commit state, an abort state, and a rollback state.
[0092] At block 706, the method 700 includes performing, by the processor 112, a distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status.
[0093] At block 708, the method 700 includes, maintaining, by the processor 112, at least one local proxy state in distributed form of the one or more transactions based on one or more conditions and the one or more mapping status, and achieve the transactional state of the one or more transactions in the synchronous mode in the workflow orchestration.
[0094] The order in which the method 700 is described is not intended to be construed as a limitation, and any number of the described method blocks may be combined or otherwise performed in any order to implement the method 700 or an alternate method. Additionally, individual blocks may be deleted from the method 700 without departing from the spirit and scope of the present disclosure described herein. Furthermore, the method 700 may be implemented in any suitable hardware, software, firmware, or a combination thereof that exists in the related art or that is later developed. The method 700 describes, without limitation, the implementation of the system 110. A person of skill in the art will understand that method 700 may be modified appropriately for implementation in various manners without departing from the scope and spirit of the disclosure.
[0095] FIG. 8 illustrates an exemplary hardware platform 800 for the implementation of the disclosed system according to embodiments of the present disclosure.
[0096] FIG. 8 illustrates a hardware platform 800 for implementation of the disclosed system 110, according to an example embodiment of the present disclosure. For the sake of brevity, the construction, and operational features of the system 110 which are explained in detail above are not explained in detail herein. Particularly, computing machines such as but not limited to internal/external server clusters, quantum computers, desktops, laptops, smartphones, tablets, and wearables which may be used to execute the system 110 or may include the structure of the hardware platform 800. As illustrated, the hardware platform 800 may include additional components not shown, and that some of the components described may be removed and/or modified.
[0097] The hardware platform 800 may be a computer system such as the system 110 that may be used with the embodiments described herein. The computer system may represent a computational platform that includes components that may be in a server or another computer system. The computer system may execute, by the processor 805 (e.g., a single or multiple processors) or other hardware processing circuit, the methods, functions, and other processes described herein. These methods, functions, and other processes may be embodied as machine-readable instructions stored on a computer-readable medium, which may be non-transitory, such as hardware storage devices (e.g., RAM (random access memory), ROM (read-only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), hard drives, and flash memory). The computer system may include the processor 805 that executes software instructions or code stored on a non-transitory computer-readable storage medium 810 to perform methods of the present disclosure. The software code includes, for example, instructions to gather data and documents and analyze documents. In an example, the modules 204, may be software codes or components performing these steps.
[0098] The instructions on the computer-readable storage medium 810 are read and stored the instructions in storage 815 or in random access memory (RAM). The storage 815 may provide a space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM such as RAM 820. The processor 805 may read instructions from the RAM 820 and perform actions as instructed.
[0099] The computer system may further include the output device 825 to provide at least some of the results of the execution as output including, but not limited to, visual information to users, such as external agents. The output device 825 may include a display on computing devices and virtual reality glasses. For example, the display may be a mobile phone screen or a laptop screen. GUIs and/or text may be presented as an output on the display screen. The computer system may further include an input device 830 to provide a user or another device with mechanisms for entering data and/or otherwise interacting with the computer system. The input device 830 may include, for example, a keyboard, a keypad, a mouse, or a touchscreen. Each of these output devices 825 and input device 830 may be joined by one or more additional peripherals.
[00100] A network communicator 835 may be provided to connect the computer system to a network and in turn to other devices connected to the network including other clients, servers, data stores, and interfaces, for instance. A network communicator 835 may include, for example, a network adapter such as a LAN adapter or a wireless adapter. The computer system may include a data sources interface 840 to access the data source 845. The data source 845 may be an information resource. As an example, a database of exceptions and rules may be provided as the data source 845. Moreover, knowledge repositories and curated data may be other examples of the data source 845.
[00101] While considerable emphasis has been placed herein on the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the invention. These and other changes in the preferred embodiments of the invention will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be implemented merely as illustrative of the invention and not as a limitation.

ADVANTAGES OF THE PRESENT DISCLOSURE
[00102] The present disclosure provides a system and a method for managing transactional states in a workflow orchestration in an e-commerce environment and travel/services booking environment.
[00103] The present disclosure provides a system and a method for handling dependency of multiple transactional states in generic fashion to drive the workflow either in forward direction or backward direction, i.e. rollback.
[00104] The present disclosure provides a system and a method for setting on products or group of products, and a trigger that are valid until the time duration set by the user.
[00105] The present disclosure provides a system and a method for using conditional offers (such as bank offers, basket offers, new user offers, and the like) and split (multiple) payment mechanisms to more than one payment instrument, in order to avail the best possible price of the product for the user.
[00106] The present disclosure provides a system and a method for enabling changes in multiple states of the one or more transaction seamlessly.
[00107] The present disclosure provides a system and a method for representing the subdomain dependency and cardinality relationship of the one or more transactional states in a simple manner.
[00108] The present disclosure provides a system and a method enabling the order management system to interact with fulfillment and accounting in an effective way.
[00109] The present disclosure provides a system and a method for facilitating backend payment which needs to interact with multiple payment gateway and wallet for a single transaction.
[00110] The present disclosure provides a system and a method for enabling real-time and robust technique to execute checkout mechanism by dealing with multiple systems like inventory, payments, and order management systems.
 
, Claims:1. A system (110) for managing transactional states in a workflow orchestration, the system (110) comprising:
one or more processors (112); and
a memory (116) coupled to the one or more processors (112), wherein said memory (116) stores instructions which when executed by the one or more processors (112) causes the system (110) to:
receive one or more data packets comprising a user request, wherein the user request pertains to one or more transactions;
manage at least one resource and corresponding transactional state of the one or more transactions in real-time, wherein the transactional state comprises at least one of: a commit state, an abort state, and a rollback state;
perform a distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status; and
maintain at least one local proxy state in distributed form of the one or more transactions based on one or more conditions and the one or more mapping status, and achieve the transactional state of the one or more transactions in the synchronous mode in the workflow orchestration.
2. The system (110) as claimed in claim 1, wherein the one or more conditions comprise at least one of: a reversal flow, a fault detection, a failure occurrence, and a delay period.
3. The system (110) as claimed in claim 1, wherein the one or more mapping status comprise:
a transaction system to identity (ID) mapping that pertains to one or more sub domains and corresponding identities along with relationship state, wherein the one or more sub domains comprise at least one of: an inventory (324), a payment (322), and a checkout (302); and
an ID to transaction state mapping that pertains to a current state and corresponding identities of the one or more sub domains, wherein the current state comprises at least one of: an active state, a pending state, and a terminated state.
4. The system (110) as claimed in claim 3, wherein the system (110) is configured to:
handle dependency of the one or more sub domains based on the transactional state to execute the workflow orchestration.
5. The system (110) as claimed in claim 3, wherein the system (110) is configured to:
perform the checkout (302) to regulate the one or more sub domains comprising at least one of: the inventory (324), the payment (322), and an order management, and enable a prepare (316) command locally in a workflow orchestrator, followed by a Remote Procedure Call (RPC) (318), and execution of the transactional state locally based on a response of the RPC.
6. The system (110) as claimed in claim 1, wherein the system (110) comprises:
a persistent layer configured to store the one or more mapping status of a closest sub domain in the distributed form, and access the transactional state across one or more Application Programming Interface (API) calls for enabling execution of the workflow orchestration.
7. The system (110) as claimed in claim 6, wherein the system (110) comprises:
a caching layer (308) coupled to the persistent layer, and configured to store the one or more mapping status to authorize access of the one or more mapping status multiple times as part of the workflow execution.

8. The system (110) as claimed in claim 7, wherein the system (110) comprises:
an Application Programming Interface (API) layer (304) configured to provide recommendations to fetch the one or more mapping status from at least one of: the persistent layer and the caching layer (308), wherein the API layer (304) comprises at least one of: a transactional API and a utility API.
9. The system (110) as claimed in claim 1, wherein the system (110) is configured to:
handle one or more concurrent calls by implementing a semantic lock mechanism in a database layer (312) and update content in records of the database layer (312).
10. A method (700) for managing transactional states in a workflow orchestration, the method (700) comprising:
receiving, by a system (110), one or more data packets comprising a user request, wherein the user request pertains to one or more transactions;
managing, by the system (110), at least one resource and corresponding transactional state of the one or more transactions in real-time, wherein the transactional state comprises at least one of: a commit state, an abort state, and a rollback state;
performing, by the system (110), a distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status; and
maintaining, by the system (110), at least one local proxy state in distributed form of the one or more transactions based on one or more conditions and the one or more mapping status, and achieving the transactional state of the one or more transactions in the synchronous mode in the workflow orchestration.

11. A non-transitory computer readable medium comprising machine executable instructions that are executable by a processor (112) to:
receive one or more data packets comprising a user request, wherein the user request pertains to one or more transactions;
manage at least one resource and corresponding transactional state of the one or more transactions in real-time, wherein the transactional state comprises at least one of: a commit state, an abort state, and a rollback state;
perform a distributed coordination for the at least one resource of the one or more transactions in a synchronous mode based on the transactional state and one or more mapping status; and
maintain at least one local proxy state in distributed form of the one or more transactions based on one or more conditions and the one or more mapping status, and achieve the transactional state of the one or more transactions in the synchronous mode in a workflow orchestration.