SYSTEMS AND METHODS FOR ENABLING TRANSACTIONS ACROSS DISPARATE DISTRIBUTED SYSTEMS
A method for enabling transactions may include defining states of a transactional system that implements the method and transitions between the states. Each transition between the states can comprise a data item. The transactional system may determine the states and the transitions between the states used by the first entity, determine the states and the transitions between the states used by the second entity, determine a required state not used by the first entity but is used by the second entity, and determine a required transition between the states. The required transition between the states is not used by the first entity but is used by the second entity. The transactional system may determine a required data item of the required transition between the states and define a handler to enable transactions between the first entity and the second entity in the transactional system.
This disclosure claims a benefit of priority under 35 U.S.C. § 119(e) from U.S. Provisional Application No. 63/334,687, filed Apr. 26, 2022, entitled “INTELLIGENT INTEGRATION SYSTEMS AND METHODS WITH DIGITAL AVATARS,” and U.S. Provisional Application No. 63/334,689, filed Apr. 26, 2022, entitled “INTELLIGENT INTEGRATION SYSTEMS AND METHODS WITH GAP ANALYSIS,” both of which are fully incorporated by reference herein for all purposes.
TECHNICAL FIELDThis disclosure relates generally to electronic information exchange in a distributed computing environment. More particularly, this disclosure relates to intelligent integration systems, methods, and computer program products that enable entities to electronically exchange information as well as documents such as Electronic Data Interchange (EDI) documents across disparate distributed systems in a way that meets complex information exchange requirements.
BACKGROUND OF THE RELATED ARTToday, enterprises and entities alike recognize the tremendous cost savings by exchanging business documents with their trading partners via an electronic communication method referred to as the Electronic Data Interchange (EDI). An electronic information exchange platform may provide various services to networked enterprise systems so that documents such as invoices, purchase orders, etc. can be exchanged over a network, for instance, using EDI. Skilled artisans appreciate that such an electronic information exchange platform has the necessary resources (e.g., hardware, software, personnel, etc.) to provide services that enable the real-time flow or exchange of information electronically in a network environment.
Given the vast amounts of data involved in the real-time flow or exchange of information electronically in a network environment, scaling up the capability of an electronic information exchange platform to perform such services in a secure, fast, and reliable manner can be problematic and cost prohibitive.
One reason why scaling up the capability of an electronic information exchange platform can be problematic and cost prohibitive is that complex and time consuming manual coding and configuration is needed for each enterprise system (client) that wants to connect to the electronic information exchange platform and for each service (which is managed and provided by the electronic information exchange platform) that each client system wants to use.
Complicating the matter is that these systems can be very diverse and may be located in various geographical and/or jurisdictional locations, with disparate formats/system/application/device requirements. Further, depending upon the roles of these client systems (e.g., buyers, sellers, suppliers, etc.), they may have very different electronic information exchange requirements. Consequently, an intelligent integration solution is needed to provide these client systems with a secure and effective way to connect, converse, and exchange information electronically, while meeting diverse and continuously changing mandates and requirements. Embodiments disclosed herein can meet this need and more.
SUMMARY OF THE DISCLOSUREIn some embodiments, a method for enabling transactions may include defining a plurality of states of a transactional system and a plurality of transitions between the states of the transactional system, wherein each transition between the states comprises a data item; defining a first entity and a second entity that transact in the transactional system; determining the states and the transitions between the states used by the first entity; determining the states and the transitions between the states used by the second entity; determining a required state in the plurality of states, wherein the required state is not used by the first entity but is used by the second entity; determining a required transition between the states in the plurality of transitions between the states, wherein the required transition between the states is not used by the first entity but is used by the second entity; determining a required data item of the required transition the between states; and defining a handler to handle the required data item, the handler used to enable transactions between the first entity and the second entity in the transactional system.
In some embodiments, the first entity is a plurality of pre-existing entities that transact in the transactional system and the second entity is a new entity to be added to the transactional system. In some embodiments, the transactional system can comprise a plurality of data enrichment rules. At least one of the plurality of data enrichment rules can be identified to provide the required data item. In some embodiments, the transactional system can further comprise a plurality of validation rules for validating at least one of the transitions between the states.
In some embodiments, the required state is a plurality of required states, the required transition between the states is a plurality of required transitions between states, and the required data item is a plurality of required data items of the plurality of required transitions between the states. In some embodiments, defining a handler to handle the required data item can comprise defining a plurality of handlers to handle the plurality of required data items. In some embodiments, a first transition between the states and a second transition between the states can have the same data item. In some embodiments, the handler can comprise an API function or an input from a user interface component.
One embodiment comprises a system comprising a processor and a non-transitory computer-readable storage medium that stores computer instructions translatable by the processor to perform a method substantially as described herein. Another embodiment comprises a computer program product having a non-transitory computer-readable storage medium that stores computer instructions translatable by a processor to perform a method substantially as described herein. Numerous other embodiments are also possible.
These, and other, aspects of the disclosure will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings. It should be understood, however, that the following description, while indicating various embodiments of the disclosure and numerous specific details thereof, is given by way of illustration and not of limitation. Many substitutions, modifications, additions, and/or rearrangements may be made within the scope of the disclosure without departing from the spirit thereof, and the disclosure includes all such substitutions, modifications, additions, and/or rearrangements.
The drawings accompanying and forming part of this specification are included to depict certain aspects of the invention. A clearer impression of the invention, and of the components and operation of systems provided with the invention, will become more readily apparent by referring to the exemplary, and therefore non-limiting, embodiments illustrated in the drawings, wherein identical reference numerals designate the same components. Note that the features illustrated in the drawings are not necessarily drawn to scale.
EbXML or e-business XML (Electronic Business using eXtensible Markup Language)—refers to a family of XML-based standards that enables the global use of electronic business information in an interoperable, secure, and consistent manner by all trading partners.
Conversation—in ebXML terminology, a conversation is a series of business message exchanges between trading partners that is predefined by a conversation definition and a fundamental step in defining a conversation is creating the workflows that execute the roles (e.g., an initiator role and a participant role). Each workflow template associated with an ebXML conversation performs only one of the two roles. In this disclosure, the term “conversation” takes on a broader meaning because the invention disclosed herein is not limited to trading partners that exchange EDI documents over an electronic information exchange platform. Rather, the invention disclosed herein can be leveraged to facilitate electronic information exchange between entities in a single enterprise and the information thus exchanged is not limited to EDI documents. A conversation typically involves two entities, referred to herein as a rule setter (or a rule-setting entity) and a rule follower (or a rule-following entity). An example of a rule setter can be a buyer or a buying entity. An example of a rule follower can be a seller or a selling entity. Thus, in this disclosure, the term “conversation” can apply to a pair of entities that converse electronically with each other where information as well as transactions are exchanged by sending messages, making application programming interface (API) calls, using the ebXML terminology, and sending signals (e.g., “order received,” “order accepted,” etc.). A conversation, therefore, can include a transaction and/or signals between a pair of entities. However, communications taking place in a conversation between a pair of entities can involve one or more other entities, for instance, a service provider for a rule-setting entity. These communications do not change the conversation between a single pair of entities into a three-way conversation, although all the entities involved in the conversation must work together to implement a meta workflow.
Meta Workflow—a choreographed workflow of workflows. There can be multiple different entities involved in a meta workflow which, in turn, can involve environment-specific workflows. An environment-specific workflow is a workflow that takes place inside a computing environment of a business entity. For instance, a rule-setting entity can have multiple applications that may work together to implement a workflow inside a computing environment of the rule-setting entity. These applications may communicate outside the computing environment of the rule-setting entity with a reusable integration component of an intelligent integration system disclosed herein.
Reusable integration component—also referred to herein as a “kit” or a “digital avatar” (“avatar”). In this disclosure, an avatar is created by the intelligent integration system disclosed herein as a representative of a computing system of an enterprise (e.g., a buyer, a seller, a supplier, a retailer, an intermediary, etc.) within a computing environment where the intelligent integration system operates. These avatars do not represent humans and are not controlled by humans.
Integration—moving data through automation, e.g., moving data from one entity to another with one or more Applications. The invention provides a reusable integration component that can integrate an entity with one or more entities that have varying data and processing requirements, such that the first can follow the varying data and process conventions of the others. For instance, in a business-to-business (B2B) integration, typically a seller (the first entity) needs to conform to the requirements of buyers (the other entities). An avatar for the first entity can be adapted to variations in the first entity. For instance, users of an application such as an ERP very often customize the ERP, and that customization can affect the data and processes of the ERP. The avatar for the first entity can be adapted to accommodate such a customization. This disclosure alters the focus of integrating with entities from sending files and making API calls to using multiple techniques to construct the data needed by the recipient (and that may involve exchanging file data and making API calls). The integration does not depend on applications to generate the data of a transaction. Rather, the invention constructs the transaction from the available data and pulls only the necessary data from the application.
Choreography—the meshing between business entities and their workflows.
Choreography key—a set of rules that must be followed by avatars involved in a choreography.
Inside a workflow, a choreography key helps sub-workflows to communicate meaningfully and collaborate.
Actor—an entity or an avatar. Both a business entity (here called an entity) and an avatar are actors. In this disclosure, an actor involves software and humans and partakes in workflows.
Transaction—business-meaningful data exchange between actors.
Handler—a component of the intelligent integration system. There can be multiple types of handlers. An avatar may make use of a handler in order to implement the requirements of some choreography key that it otherwise could not implement.
The invention and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known starting materials, processing techniques, components, and equipment are omitted so as not to unnecessarily obscure the invention in detail. It should be understood, however, that the detailed description and the specific examples, while indicating some embodiments of the invention, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions, and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.
An information exchange platform operating in a network environment has the necessary resources (e.g., hardware, software, personnel, etc.) to provide managed services that enable the real-time flow or exchange of information electronically in the network environment in a secure, fast, and reliable manner, between and among disparate operating units, regardless of their standards preferences, spoken languages, or geographic locations. In this disclosure, an operating unit may represent a company, a corporation, an enterprise, an entity, or a division thereof (which is collectively referred to herein as an “entity”). Examples of a network environment may include a distributed computer network or a cloud-based computing environment. Non-limiting examples of managed services may include translation services, format services, copy services, email services, document tracking services, messaging services, document transformation services (for consumption by different computers), regulatory compliance services (e.g., legal hold, patient records, tax records, employment records, etc.), encryption services, data manipulation services (e.g., validation), etc.
The information exchange platform operates to facilitate the real-time flow or exchange of information between disparate entities regardless of standards preferences, spoken languages, or geographic locations. The information exchange platform may be embodied on server machines that support the electronic communication method (e.g., EDI, API, etc.) used by various computers (i.e., client systems of the information exchange platform) that are independently owned and operated by different entities. In some embodiments, data formats supported by the information exchange platform may include EDI, XML, ebXML, RosettaNet, EDI-INT, flat file/proprietary format, etc. Supported network connectivity may include dial-up, frame relay, AS2, leased line, Internet, etc. Delivery methods supported by the information exchange platform may include store-and-forward mailbox, event-drive delivery, etc. Supported transport methods may include Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Simple Mail Transfer Protocol (SMTP), etc. Network security protocols supported by the Trading Grid may include Secure Socket Layer (SSL), Secure/Multipurpose Internet Mail Extensions (S/MIME), Internet Protocol Security (IPSEC), Virtual Private Network (VPN), Pretty Good Privacy (PGP) encryption protocol, etc.
An intelligent integration system disclosed herein may leverage the information exchange platform to enable choreographed entity-to-entity conversations. As alluded to above, a business entity (e.g., an enterprise, a corporation, a division in a company, or some other collaboration of people making using of software applications and automation as part of their business) may follow conventions for achieving a particular goal. This orchestrated or choreographed pattern of activity is referred to a workflow. When two or more business entities collaborate, the workflows of each business entity must mesh to some degree. In this disclosure, the meshing between business entities (and their workflows) is referred to as a choreography. Thus, there can be workflows within workflows: an application used by a business entity has a workflow composed of the application and the people who use it; when people utilize two or more applications to achieve a purpose, they form a new workflow composed out of smaller, application-centric workflows; and now when business entities collaborate, a new meta workflow is formed out that utilizes workflows within the business entities.
In some cases, participants in a business process may not have an application that allows it to anchor the implementation of the business process. Previously, this is solved by modeling the business process so that humans can be the primary implementers of the business process by using a UI. This invention extends this previous solution in a novel way to itself drive the implementation of the process for machine-to-machine communication. As illustrated in
As workflows are combined into larger workflows, there can be a proliferation of choreographies. Each choreography follows rules, which are referred to as a choreography key. A ballet involves symbols—a leap into the air might illustrate strong emotion—and the more the audience understands the symbols, the performance shifts from people moving around on stage doing impressive things into communication from the performers to the audience. Likewise, inside a workflow, the choreography key helps sub-workflows communicate meaningfully and collaborate. In addition, some entity needs to define the choreography key and often one of the business entities defines the choreography key to fit its workflows and then expects other business entities to conform to that choreography key.
It is often the case that two business entities find that their workflows do not have a simplistic meshing and so one entity has to conform to the choreography key of the other. This can be challenging. To this end, the intelligent integration system provides an avatar as a digital representative of a business entity that reflects the choreography required by the business entity in order to succeed with other choreographies. Thus, an avatar has its own sub-workflow and follows two or more conversation keys. An avatar may make use of a handler in order to implement the requirements of some choreography key that it otherwise could not implement. Both a business entity (here called an entity) and an avatar are actors. In this disclosure, an actor involves software and humans and partakes in workflows. An actor participating in a choreography can invoke an activity in response to data arriving from another actor, to prepare data for another entity, and for other purposes. The term “transaction” is used here to describe business-meaningful data between actors. The choreography key defines the rules around data format, sequencing, etc. for transactions.
In the example of
For instance, if the insurance provider consistently gets spreadsheet data from employers, the intelligent integration system can convert the spreadsheet data into the data format required by its own choreography key. While not all “somethings in the middle” normalize data, they all have activities. In this example, the spreadsheet or other data moving through a choreography is defined and governed by the choreography key.
When a single choreography collaborates with multiple other choreographies, is often less effort to use activities that convert transactions into a normalized representation and then convert that data into the transaction required by the recipient choreography key. Converting transactions into the normalized form can be called normalization and converting from the normalized form into a transaction can be called particularization. This approach produces an additional choreography composed of the normalized data representation, as illustrated in
Following the example of
These avatars formalize the idea of an actor that can mimic and represent the interests of another actor. This approach involves formalizing interactions between actors via choreography keys, hereinafter referred to as signatures.
A state indicates the status of a conversation. The actions taken during the conversation bring the conversation to states and each state indicates the next actions that can be taken. Thus, there needs to be one or more automated or human entities that can take responsibility for the next step (except for end states, which might not have a next step). Table 1 below shows some example states and the entities that can trigger the next step:
Using the last example, the Waiting for Approval to Treat a Patient state, the entities in the conversation are:
-
- Medical provider
- Insurance company
- System component (e.g., a conversation manager) that is tracking the conversation and can alert the other parties that the Service Level Agreement has not been met and that the request has been voided
In this case, the patient is in the conversation, but is not an active participant in this state. Thus, being able to conduct a conversation requires that one or more entities take responsibility for the exit criteria of all states except end states.
For instance, in the Waiting for Approval to Treat a Patient, the system component could be the only participating entity taking responsibility, thus ensuring that the “Approval received” transition from the state will never occur, and that additional configuration information would be needed to ever conduct a successful conversation. For instance, the system component could provide a user interface (UI) so that human users who are part of the Medical Provider or Insurance Company can trigger the actions for exiting the state.
Being able to successfully conduct (e.g., through a conversation manager of the system) a conversation requires that the necessary entities are all engaged and are able to trigger the exit criteria. Since the focus of the invention is how to enable automation, the attention is now directed to how handlers can be identified, registered, and utilized.
Foundational to the invention is having a set of known states. Then the signature of a handler for a state is: (state, data-in, criteria, data-out, endpoint):
-
- state: the state, which is one of the known states
- data-in: the data element & structure of the data the handler needs to enter the state
- criteria: any rules on the data-in that indicate whether the handler is able to participate in the state
- data-out: any response from the handler, such as if the application etc. behind the handler rejecting entering the state
- any information about an API call, URL, etc. needed for the handler to interact with outside resources to enter the state
Examples of handlers for state transitions, including missing state transitions, include:
-
- Send a SMS message each time a certain kind of transaction is received. This handler can be triggered each time the state is entered and thus has a post state.
- Send email alerts when in the Waiting for Response for Price of Insurance state (see above) and the request is 12 hours, 6 hours, and 1 hour from timing out. This handler does not alter the state—which is very similar to saying that the prior and post state are the same.
- Generate and send a transaction to an endpoint upon receipt of a notification to exit a state. This handler might send an invoice once the data for an invoice is available and all conditions for sending the invoice are met.
The signature is: (pre-states, post-state, data-in, criteria, data-out, action, endpoint), where
-
- pre-states is the set of states prior to the action
- post-state is the state that can be the new states once the handler is invoked
- action is what to do, such as to run a script, when the handler is invoked
If a post-state but no pre-state is indicated, then the handler will be invoked each time the state is entered. If one or more pre-states are present but no post-state, then the handler will be invoked each time a state in the pre-states is exited.
For missing data, a handler can acquire missing data and provide data as needed. For instance, if a state transition can occur once three additional pieces of data are available, one or more data handlers can be used to acquire that data. Data handlers include:
-
- Place a request for data into a queue so that a human provides the needed data
- Make an API call to an application to look up data values
- Place a request on a queue and wait for a data file to appear on disk in order to retrieve the needed data
Missing data handlers to not indicate a target state, but may be used to provide data for another handler to enable it to have sufficient data-in. Similarly, a data handler may be used to record data, such as might be required by a state transition handler.
The signature is: (states, data-in, criteria, data-out, action, endpoint), where
-
- states are a set of states in which this handler can be used
- data-in often indicates query conditions, such as a document identifier, that can be used to fetch the necessary values
As alluded to above, an avatar is a reusable integration component (or module) of the intelligent integration system disclosed herein. As illustrated in
In the terminology of
In the example of
-
- A data model (“canonical” in
FIG. 10 ) for that “standard” that holds the cumulative data needed for a business process (e.g., for the choreography that starts once an order arrives from a buyer) - Transactions (e.g., purchase orders, invoices, insurance registrations, and so on)
- Set of states (e.g., the buyer sent an order, but it has not been acknowledged) and rules for transitioning between states (e.g., the supplier is acknowledging the order) organized into a state machine
- Requirements on the data for each buyer and state, that configure what canonical data items appear in web forms and what data requirements need to be met in order to transition between states
- Validation business rules to guide the user and to protect from sending bad data
- UI forms for the different process steps and transactions
- A data model (“canonical” in
In addition, the system provides a powerful “enrichment service” that enables autofill. For instance, if a prior transaction in a choreography (such as an order transaction that triggers a business process) contains a piece of data that is needed in a later transaction (e.g., a shipment notice transaction), the system “auto-fills” that data on the UI form. This powerful capability is based on the transactions and the cumulative data of a business process held in the canonical data model, and can be leveraged by the modules.
To illustrate the complexity and versatility of the invention, more formal notation is provided as follows.
The invention provides integration automation around a business process P. A set of electronically communicating entities E all follow P, but with individual variation. Other entities C will need to follow the business process P with one or more entities in E. P is an abstract description encompassing the range of the common patterns, conventions, standards, or other commonalities in how entities in E choose to communicate electronically. P defines the scope of behaviors that entities in C might need to implement in order to participate in the business process with entities in E.
Thus, P can be defined as: P={M, S, L, V, T, F, I}, where
-
- M: the data model of all data groupings and items, with multiplicity, for the business process
- S: the set of states of the business process
- L: the set of standard transitions (“links” in a graph of states) allowed between states
- V: the set of standard validation rules on the data for transitioning over some link in L
- T: the set of transactions composed of data items in M that can be sent to an external party or received from an external party as part of a transition in L, and the data of some t in T might be sent as a message, through data on a stream, via API calls, etc.
- F: the enrichment, or auto-fill, rules for populating data in some transaction in T for some transition in L
- I: the initial set of transactions in T that initiate a business process
The entities e in E have varying requirements in how they follow P. For instance, one entity e in E may require that a given data item in some transaction in T must be populated with a data value, and another entity fin E does not require that the same data item have a value. e may allow a given state transition in L and another will not.
For instance,
An application run by an entity has a state change (e.g., change to an order/respond to an order, etc.). The intelligent integration system listens (through its avatar using the API) to events which indicate a state change, query (through an avatar of the entity using the API) the application, and determine whether it is an important event that can cause change in integration. The determination (the avatar chooses whether to suppress the event or act on it which causes a state change) which changes
In this way, it is possible to specify the communications requirements of some entity e in E as P(e) as a valid conforming variant of P. This is shown in
In conducting a gap analysis, the system looks at each link and determine whether it can be successfully executed. For example, P(e) will typically only allow a subset of the states in S and the state transitions in L of the transactions in T, but will typically have additional validation rules in V. However, e will typically not send and receive data that precisely conforms to the data of each tin T. Thus, data transformation rules are needed for converting between e's data and the transactions defined in T. This and other additional information can be included in Other(e). P(e) is the variations in P required by e in E, and Other(e) includes the additional information needed for some c in C to follow P(e) with e.
As a non-limiting example, suppose an employer works with a Worker's Comp insurance company that handles Worker's Comp claims and works with a medical insurance company that processes medical claims. An employee is hurt on the job and unable to work for a period of time, so the employer puts the employee on a long term leave. The medical insurance company pays medical claims. The initial state would be that the employee is injured. A state change indicates that the employee starts receiving a disability payment. The state changes when the employee's medical claim is processed. In this example, a first entity represents the employer (with a first avatar representing an HR system run by the first entity), a second entity represents the Worker's Comp insurance company, and a third entity represents the medical insurance company. The third entity wants to be notified about the employee's medical claim, but will not care about the state change for starting payment of disability. Likewise, the second entity cares about the state change for starting disability payments, but will not care about the state change for processing a medical claim.
In some cases, the second and the third entities may represent different departments of the same insurance company. The system may use a state machine for tracking the overall state and may use substate machines for tracking different data/different state changes. In some embodiments, an avatar may communicate with multiple computing systems in one entity or across entities based on what information is needed. Modeling an overall state (in a state machine) that manages a subset of states (substate machines), with metadata attached thereto, can be rather complex as it models behaviors and multiple possible states can exist simultaneously at any given time.
To this end, as illustrated in Table 2, the states and the transitions can be represented using data structures. For instance, a table can represent the subset of states of P required for e1 in E, where a y indicates that e1 uses a state.
Table 3 below illustrates a table of transitions as used by e1 (only a subset of the possible allowed transitions are listed—not everything in P is listed):
The set C is the communicating entities C that implement the “other side” of P(e). That is, if e in E sends a transaction i in I, then c in C will receive i and will follow the “other side” of the choreography by supplementing P(e) with Other(e). (Note: a single entity might be in both C and E and thus can play both roles of P).
When communicating entity e in E sends a transaction i in I to c in C, then c must instantiate the data of P(e) for i. c must create an empty data set d conforming to M. c will transform the data sent by e into i by using the mapping rules defined in Other(e) and then populate d with the data of i, which is referred to as d(i). c will also record state information, such as the current state s, the identify of sender e, into d. This is illustrated in
In
Previously, P(e) and Other(e) are part of a standard avatar. Additionally, the system can include validation rules v in V. For a given state transition, a validation rule can indicate information such as:
-
- A delivery dock code must be present. Under the covers, the rule would verify that some Identifier structure in Document/Header/Identifiers/Identifier has a @function with the value “DeliveryDockCode” and the *body for that Identifier holds a value with the specified data type.
Other kinds of validation rules may also be used. As with the states and transitions, the validation rules can be represented in a table.
In some cases, c can have internal automation, such as applications, that participate in c's implementation of P(e). The data of d may need to be transformed and inserted via APIs into an Application maintained by c, as shown in
This set of behaviors, data mappings, applications, etc. are referred to as the implementation(P). This implementation includes the infrastructure and processes for a c in C to implement P for a given set of entities in E. If c needs to respond to message i, then c needs to transition via some link in L and send a response message tin T to e, and t must meet the necessary validation rule in V. To assist in this, enrichment fin F will auto-populate some of the data of t. In general, f will populate as much of the data as possible. A human using a UI or app or automation such as an application must provide the remainder of the information, and can correct information provided by f.
However, if c in C desires to implement P for another communicating entity fin E, the current Implementation(P) might not meet every requirement of P(f). In particular, if automation involving applications etc. is involved in Implementation(P), communicating with an additional entity fin E requires that Implementation(P) meet all the requirements of P(f).
In looking at the automation in c, such as an Application, one might think that standardized automation for a given Application a might suffice for all c in C. For instance, many applications ship with standard APIs, have standard data and process models, and can communicate with standard file format. However, many c in C will customize their Applications. This can alter the file formats, the data of the API calls, can introduce new API calls or file types, etc. In other words, when an application is configured to meet the specialized needs of c in C, then the automation for letting the Application participate in Implementation(P) must change. Thus, the invention needs to flex to easily adapt to customizations made to Applications used by some c in C.
Accordingly, if a company c in C wants to communicate with additional companies in E, the current Implementation(P) meets the requirements of the current P(e1), P(e2), . . . , and must be adjusted to meet requirements of additional P(en), P(en+1) . . . etc.
P(e) and Other(e) already exist for each additional e in E that c desires to communicate with, or else the P(e) and Other(e) will need to be built. Supporting another P(e) may cause changes in Implementation(e) such as additional:
-
- States in S and transitions in L
- Validations in V
- Transactions in T and I
- Data values needed in transactions in T that are already sent to other entities in E
In addition, when communicating with an additional entity e, it is not desirable to alter how data is exchanged with existing partners in E—Implementation(P) should not alter its behavior for existing P(e). As discussed above, the system provides a pre-built library of P(e) and Other(e) so that an entity c in C can communicate with multiple entities in E, and can with reduced effort utilize P for additional entities in E. In this context, the invention can assist companies in C with machine-to-machine communications with one or more companies in E over process P.
Previously, when some e in E sends transaction i in I to initiate a business process, data store d will be instantiated and will be populated with the data of i and with additional information such as the sender and the initial state s in S. This is referred to as d(i). As the business process begun by I continues, as c and e send additional transactions tin T, values will be added to and updated in d(i). Thus, previously, the system is able to partially populate the data of t by using auto-fill fin F and then a human will add the remaining data. The data is mapped to e's data format for the data of T, and is delivered by some mechanism (e.g. by sending a file, through API calls, etc.).
Previously, the system can also intake incomplete data for t that is sent from an Application, import it into d(i), and then use f to populate t with data and if needed ask the user to supply the needed additional values. In this case, an Application provides the trigger for moving the state of the conversation in d(i) to another state. And if some P(e) requires data that neither the application nor d(i) holds, that data must be provided manually.
However, when c integrates (moves data through automation) with one or more Applications as part of Implementation(P), and then c wishes to converse over P with an additional e in E, the effort can be disruptive and highly manual. Making changes to an application to support an additional e is highly undesirable. In addition, refining an Application can cause manual and undesirable activity to ensure that the integrations of Implementation(P) continue to work as desired.
While the system takes control of the conversation P(e) so that c can meet e's requirements, the invention disclosed herein pushes the boundaries farther. For instance, the invention:
-
- Extends P to have a set of configurable event handlers H that can trigger integration activities to
- populate the data of some transaction t for e elsewhere (instead of simply invoking f on d(i) to populate t with data and then asking a human to add the missing values)
- push data from t or d(i) (instead of generating a file for something else to pick up)
- Events can come from anywhere, not just from a human through the UI, from e, or from an Application
- Handlers can interact with multiple APIs, files, databases, etc. to extract or inject necessary data
- Adapts to customizations made to an Application through configuration files that guide the behavior of the event handlers of H, thus also buffering the integration from changes made to an Application
- Applies automation to adapt to new requirements for P(e) for an additional e in E and provides a gap analysis for any missing items of data that handlers in H cannot already provide
- Extends P to have a set of configurable event handlers H that can trigger integration activities to
From another perspective, the invention provides the equivalent of intelligent agents for interacting with the Applications etc. in c in order to address the needs of P(e1), P(e2), . . . , P(en) and any new P(en+1) that c wishes to support.
In some embodiments, for Implementation(P) meeting the needs of P(e1), P(e2), . . . , P(em), in order to also meet the requirements of P(em+1), . . . , P(en), the system is operable to make sure that an updated Implementation(P) is capable of meeting the extended requirements. In a choreography with some entity e in E, the only a subset of Implementation(P) is likely to be needed, but there should be no requirement for some fin E that and updated Implementation(P) cannot address should f require it. Note, since Other(e) already exists, data mappings and other requirements to communicate with e are already addressed.
In some embodiments, the system is operable to address:
-
- The additional states in S and transitions in L are the states and transitions P(em+1) U . . . U P(en) that are not already in Implementation(P)
- Each message tin T not already in Implementation(P)
- Each validation rule r in some v in V required by P(em+1), . . . , P(en) that is not already in Implementation(P) may indicate additional requirements to be able to populate data values in messages in T
In some embodiments, P is updated to include H:
P={M, S, L, V, T, F, I, H}, where H is the set of (event, handler) tuples such that when the event is triggered, the handler is invoked.
For data arriving by file, API, or some other means to a c in C from an e in E, for a process that was previously initiated by a message i from e,
In the example of
However, since d(i) holds the necessary state of P(e), it is also entirely possible that the arrival of the data and the event raised by that arrival does not trigger an event handler. This is illustrated in
In the example of
-
- For a supply chain or logistics business process, none of the applications are able to handle the kind of shipment (e.g. a drop ship)
- For healthcare data, none of the applications might be able to handle certain kinds of medical reports, but d(i) will contain the repository of that data so it is available should a healthcare professional need access to it
- For error conditions relating to conveying data to/from e or an Application, d(i) can hold that error state information until the error is resolved
When an event is raised, handlers may pull data from Applications to update the information in d(i) so it has the necessary data for some tin T to be sent to e. The implementation for generating a transaction t to be sent to e will:
-
- 1. Identify the subset of t that e requires or will optionally accept. This subset is referred to as t′.
- 2. Use handlers to collect the available data values of t′ as described above and record the data values into d(i). This step can add additional values or overwrite values in d(i).
- 3. Invoke the enrichment auto-fill rule F to populate as much of t′ as possible.
Once completed, can be validated etc. and appropriate measures taken.
A handler h in H can have custom behaviors, but can also make use of configurable behaviors. This configurability enables the handler to adapt to customizations made by c to one or more Applications. For an API. For a data item in M (and thus in d(i)), the handler has access to records indicating:
-
- The data item
- The API call for fetching or putting the data item
- Query information for the API call (e.g. for healthcare data, the patient id and doctor visit id)
- The location of the needed data value in the response to the API call
For files generated by Applications, the handler can make use of:
-
- The data item
- The file or report generated by the Application or consumed by an application
- Query information into the file (e.g. for a sellable item, the location of the item id)
- The location of the needed data value
For acquiring data, the information can be queried and d(i) updated, and often multiple values needed in d(i) can be fetched via a single API call or from a single file. For pushing data from the invention, entire payloads of API calls or entire files may need to be generated. In both cases, the invention relies on data maps, as discussed above, but also allows configurable “overrides” that update the behavior of the map for the variations in the data.
In some embodiments, the system may perform an impact/gap analysis at design time, for instance, when a c requests that an implementation (P) be analyzed to identify the gaps that need to be addressed to meet the needs of entities em+1, . . . , en. The impact/gap analysis:
-
- Identifies the new states and transitions that are in P(em+1) U . . . U P(en), but not in the current Implementation(P). New transitions that are not already in Implementation(P) will need to be handled.
- Identifies the data of each transaction t of T that is required by P(em+1) U . . . U P(en) where that data item is not required by tin the current Implementation(P). This may mean that entire transactions in I and T will now be exchanged with an entity e in E. Note since tin T is an extract of d which conforms to model M, then identifying a data item in t is also identifying a data item in d. Data items of some t not currently in Implementation(P) can be handled in several ways.
For instance,
Table 5 below shows how the states used by e1 and e2 as (showing only a part of the overall table of transitions in P) can be represented in a table.
Similarly, if e1 and e2 both share a transition, the validation rules for that transition can be compared and a list of gaps can be provided. For instance, the validation rules can be represented as illustrated in Table 6 below.
In this portion of the validation rules for e1 and e2, it can be seen that the data field/Document/Header/Identifiers/Identifier[@function=“AccountCode”]/*body must hold a numeric value in order to Implementation(P) that supports e1 to also support e2.
To identify how a handler may satisfy the need for the value for data items, such as the field/Document/Header/Identifiers/Identifier[@function=“AccountCode”]/*body, the invention leverages information about different applications. An example is shown in Table 7 below.
In this case, “Application 5” and “application 6” are placeholders into either the standard configuration of different applications such as SAP, Netsuite etc., or may signify how to access data in an application that has been customized. In some embodiments, the system can automatically identify that if the company c in C uses Application 6, and needs the value/Document/Header/Identifiers/Identifier[@function=“AccountCode”]/*body, the handler can use the accountInfo API call and retrieve the data value of/account/code. In some embodiments, different API calls can have query conditions that are not specifically mentioned here. Similarly, a handler can indicate in a file format the location of data values. In some embodiments, a new handler can be generated by reconfiguring and/or modifying an existing handler so as to adapt and be able to provide the necessary information.
In some embodiments, once Implementation(P) has been compared with the requirements for integrating with e2, the automatic adaptations and the remaining gaps can be summarized in a report for human review.
In some embodiments, to address any gaps flagged by the system:
-
- 1. States and Transitions: Implementation(P) will automatically track the new state because the P(e) for the new e in E will have that state. By registering the P(e) with Implementation(P), the new states will also registered. This then raises the following considerations for each new state:
- a. Does any Application in C's environment care about the state, or is some Application or other entity in c responsible for triggering the event for transitioning from the state? If so, then handlers may need to be updated. If not, no action is needed.
- 2. Additional data items in some tin T that are sent out: If additional data is needed for some tin T because the data item will not be in d(i), or a new transaction in T is required and not all the needed data will be in d(i), and if the handler configurations cannot handle those data items, then the options are:
- a. Add additional handler configuration data to acquire the data items on demand
- b. Allow a human to supply those data values
- 3. Additional data items in some tin T that is received from an e in E: if an Application requires that data item for its processing, or if it is desired that some report or other entity in c should receive that data, and if the handler configurations cannot push that data, then the options are:
- a. Add additional handler configuration data to push the data items
- b. Enable entities in c to query d(i) to fetch the data values on demand
- 4. Specification and Testing: the invention can generate specification information for handlers and engage in test choreographies, simulating the behavior of an e in E to ensure that the handlers are behaving correctly prior to testing with e.
- 1. States and Transitions: Implementation(P) will automatically track the new state because the P(e) for the new e in E will have that state. By registering the P(e) with Implementation(P), the new states will also registered. This then raises the following considerations for each new state:
Although not discussed here, entities in c can query d(i) through API or by generating data files on demand.
Thus, the invention disclosed herein can:
-
- streamline the process of c identifying the impact of participating in P with e (thus allowing c to consider the effort and time needed before it could participate in P with e);
- automatically and silently handle new requirements in P(e) for a new e in E; and
- enable humans to minimize any manual work or integration changes for handling P(e) for a new e in E.
As alluded to above, typical implementations of P are application-centric: it is assumed that the application will generate the data values, or that an application can be queried to retrieve the values, and if they can't, then often-difficult human effort will supply the missing data. Contrastingly, the invention disclosed herein is business-process-centric: the applications, application networks, etc. will be queried only to supply missing data values or to override default data values, and the data values are added to business process data store d(i) and then processed. In this way, human input such as through a UI is minimized, as that is not sustainable as transaction volume increases.
Further, as discussed, integration requirements might change by c starting to work with an additional e in E, by an e in E altering its requirements, by an Application configuration change, and so on. This invention creates an automated ability for ensuring that d(i) will continue to be automatically populated with data even when integration requirements change.
The prior authorizations and payments workflow shown in
However, as discussed above with reference to
As a non-limiting example, requirements on data “in the middle” can include: structure of the data (e.g., what is mandatory, data types, etc.), workflow requirements (e.g., later transactions in the workflow must include identifier values from earlier transactions, etc.), co-variance (e.g., if A is present, then B must have a value (AND), if C is not present, then D must have a value (OR), etc.), agreed-upon-data (e.g., a dermatologist wanting to do an open-heart surgery would fall outside the agreement between these communicating entities, etc.), and so on. Other data requirements may also be possible.
For the purpose of illustration, a single system is shown for each of computers 3012, 3015, and 3016. However, within each computer, a plurality of computers (not shown) may be interconnected to each other over network 3014. For example, a plurality of entity A computers and a plurality of entity B computers 3015 may be coupled to network 3014. Each computer may include a data processing system for communicating with an electronic information exchange platform. In some embodiments, computer 3016 may operate in the computing environment that supports the electronic information exchange platform.
Computer 3012 can include central processing unit (“CPU”) 3020, read-only memory (“ROM”) 3022, random access memory (“RAM”) 3024, hard drive (“HD”) or storage memory 3026, and input/output device(s) (“I/O”) 3028. I/O 3029 can include a keyboard, monitor, printer, electronic pointing device (e.g., mouse, trackball, stylus, etc.), or the like. Computer 3012 can include a desktop computer, a laptop computer, a personal digital assistant, a cellular phone, or nearly any device capable of communicating over a network. Computer 3015 may be similar to computer 3012 and can comprise CPU 3050, ROM 3052, RAM 3054, HD 3056, and I/O 3058.
Likewise, computer 3016 may include CPU 3060, ROM 3062, RAM 3064, HD 3066, and I/O 3068. Computer 3016 may include one or more backend systems configured for providing a variety of services to computers 3012 and 3015 over network 3014. Many other alternative configurations are possible and known to skilled artisans.
Each of the computers shown in
Portions of the methods described herein may be implemented in suitable software code that may reside within ROM 3022, 3052, or 3062; RAM 3024, 3054, or 3064; or HD 3026, 3056, or 3066. In addition to those types of memories, the instructions in an embodiment disclosed herein may be contained on a data storage device with a different computer-readable storage medium, such as a hard disk. Alternatively, the instructions may be stored as software code elements on a data storage array, magnetic tape, floppy diskette, optical storage device, or other appropriate data processing system readable medium or storage device.
Those skilled in the relevant art will appreciate that the invention can be implemented or practiced with other computer system configurations, including without limitation multi-processor systems, network devices, mini-computers, mainframe computers, data processors, and the like. The invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured, or constructed to perform the functions described in detail herein. The invention can also be employed in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network such as a local area network (LAN), wide area network (WAN), and/or the Internet. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. These program modules or subroutines may, for example, be stored or distributed on computer-readable media, including magnetic and optically readable and removable computer discs, stored as firmware in chips, as well as distributed electronically over the Internet or over other networks (including wireless networks). Example chips may include Electrically Erasable Programmable Read-Only Memory (EEPROM) chips. Embodiments discussed herein can be implemented in suitable instructions that may reside on a non-transitory computer readable medium, hardware circuitry or the like, or any combination and that may be translatable by one or more server machines. Examples of a non-transitory computer readable medium are provided below in this disclosure.
ROM, RAM, and HD are computer memories for storing computer-executable instructions executable by the CPU or capable of being compiled or interpreted to be executable by the CPU. Suitable computer-executable instructions may reside on a computer readable medium (e.g., ROM, RAM, and/or HD), hardware circuitry or the like, or any combination thereof. Within this disclosure, the term “computer readable medium” is not limited to ROM, RAM, and HD and can include any type of data storage medium that can be read by a processor. Examples of computer-readable storage media can include, but are not limited to, volatile and non-volatile computer memories and storage devices such as random access memories, read-only memories, hard drives, data cartridges, direct access storage device arrays, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices. Thus, a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like.
The processes described herein may be implemented in suitable computer-executable instructions that may reside on a computer readable medium (for example, a disk, CD-ROM, a memory, etc.). Alternatively, the computer-executable instructions may be stored as software code components on a direct access storage device array, magnetic tape, floppy diskette, optical storage device, or other appropriate computer-readable medium or storage device.
Any suitable programming language can be used to implement the routines, methods or programs of embodiments of the invention described herein, including C, C++, Java, JavaScript, HTML, or any other programming or scripting code, etc. Other software/hardware/network architectures may be used. For example, the functions of the disclosed embodiments may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.
Different programming techniques can be employed such as procedural or object oriented. Any particular routine can execute on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors. Data may be stored in a single storage medium or distributed through multiple storage mediums, and may reside in a single database or multiple databases (or other data storage techniques). Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time. The sequence of operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. The routines can operate in an operating system environment or as stand-alone routines. Functions, routines, methods, steps and operations described herein can be performed in hardware, software, firmware or any combination thereof.
Embodiments described herein can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium, such as a computer-readable medium, as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in the various embodiments. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the invention.
It is also within the spirit and scope of the invention to implement in software programming or code an of the steps, operations, methods, routines or portions thereof described herein, where such software programming or code can be stored in a computer-readable medium and can be operated on by a processor to permit a computer to perform any of the steps, operations, methods, routines or portions thereof described herein. The invention may be implemented by using software programming or code in one or more digital computers, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. In general, the functions of the invention can be achieved by any means as is known in the art. For example, distributed, or networked systems, components and circuits can be used. In another example, communication or transfer (or otherwise moving from one place to another) of data may be wired, wireless, or by any other means.
A “computer-readable medium” may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, system or device. The computer readable medium can be, by way of example only but not by limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, system, device, propagation medium, or computer memory. Such computer-readable medium shall generally be machine readable and include software programming or code that can be human readable (e.g., source code) or machine readable (e.g., object code). Examples of non-transitory computer-readable media can include random access memories, read-only memories, hard drives, data cartridges, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices. In an illustrative embodiment, some or all of the software components may reside on a single server computer or on any combination of separate server computers. As one skilled in the art can appreciate, a computer program product implementing an embodiment disclosed herein may comprise one or more non-transitory computer readable media storing computer instructions translatable by one or more processors in a computing environment.
A “processor” includes any, hardware system, mechanism or component that processes data, signals or other information. A processor can include a system with a general-purpose central processing unit, multiple processing units, dedicated circuitry for achieving functionality, or other systems. Processing need not be limited to a geographic location, or have temporal limitations. For example, a processor can perform its functions in “real-time,” “offline,” in a “batch mode,” etc. Portions of processing can be performed at different times and at different locations, by different (or the same) processing systems.
As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited only those elements but may include other elements not expressly listed or inherent to such process, product, article, or apparatus.
Furthermore, the term “or” as used herein is generally intended to mean “and/or” unless otherwise indicated. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). As used herein, a term preceded by “a” or “an” (and “the” when antecedent basis is “a” or “an”) includes both singular and plural of such term, unless clearly indicated otherwise (i.e., that the reference “a” or “an” clearly indicates only the singular or only the plural). Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. Additionally, any signal arrows in the drawings/figures should be considered only as exemplary, and not limiting, unless otherwise specifically noted. The scope of the disclosure should be determined by the following claims and their legal equivalents.
Claims
1. A method for enabling transactions, comprising:
- defining a plurality of states of a transactional system and a plurality of transitions between the states of the transactional system, wherein each transition between the states comprises a data item;
- defining a first entity and a second entity that transact in the transactional system;
- determining the states and the transitions between the states used by the first entity;
- determining the states and the transitions between the states used by the second entity;
- determining a required state in the plurality of states, wherein the required state is not used by the first entity but is used by the second entity;
- determining a required transition between the states in the plurality of transitions between the states, wherein the required transition between the states is not used by the first entity but is used by the second entity;
- determining a required data item of the required transition the between states; and
- defining a handler to handle the required data item, the handler used to enable transactions between the first entity and the second entity in the transactional system.
2. The method of claim 1, wherein the first entity is a plurality of pre-existing entities that transact in the transactional system and the second entity is a new entity to be added to the transactional system.
3. The method of claim 1, wherein the required state is a plurality of required states, the required transition between the states is a plurality of required transitions between states, and the required data item is a plurality of required data items of the plurality of required transitions between the states, wherein defining a handler to handle the required data item comprises:
- defining a plurality of handlers to handle the plurality of required data items.
4. The method of claim 1, wherein a first transition between the states and a second transition between the states have the same data item.
5. The method of claim 1, wherein the transactional system further comprises a plurality of data enrichment rules, further comprising:
- identifying at least one of the data enrichment rules to provide the required date item.
6. The method of claim 5, wherein the transactional system further comprises a plurality of validation rules for validating at least one of the transitions between the states.
7. The method of claim 1, wherein the handler comprises:
- an application programming interface function or an input from a user interface component.
8. A system for enabling transactions, comprising:
- a processor; and
- a memory coupled to the processor, the memory comprising instructions that when executed by the processor, perform a method comprising: defining a plurality of states of a transactional system and a plurality of transitions between the states of the transactional system, wherein each transition between the states comprises a data item; defining a first entity and a second entity that transact in the transactional system; determining the states and the transitions between the states used by the first entity; determining the states and the transitions between the states used by the second entity; determining a required state in the plurality of states, wherein the required state is not used by the first entity but is used by the second entity; determining a required transition between the states in the plurality of transitions between the states, wherein the required transition is not used by the first entity but is used by the second entity; determining a required data item of the required transition between the states; and defining a handler to handle the required data item, the handler used to enable transactions between the first entity and the second entity in the transactional system.
9. The system of claim 8, wherein the first entity is a plurality of pre-existing entities that transact in the transactional system and the second entity is a new entity to be added to the transactional system.
10. The system of claim 8, wherein the required state is a plurality of required states, the required transition between the states is a plurality of required transitions between the states, and the required data item is a plurality of required data items of the plurality of required transitions between the states, wherein defining a handler to handle the required data item comprises:
- defining a plurality of handlers to handle the plurality of required data items.
11. The system of claim 8, wherein a first transition between the states and a second transition between the states have the same data item.
12. The system of claim 8, wherein the transactional system further comprises a plurality of data enrichment rules, further comprising:
- identifying at least one of the data enrichment rules to provide the required date item.
13. The system of claim 12, wherein the transactional system further comprises a plurality of validation rules for validating at least one of the transitions between the states.
14. The system of claim 8, wherein the handler comprises:
- an application programming interface function or an input from a user interface component.
15. A computer programming product comprising a non-transitory computer readable medium storing instructions executable by a processor for enabling transactions, comprising:
- defining a plurality of states of a transactional system and a plurality of transitions between the states of the transactional system, wherein each transition between the states comprises a data item;
- defining a first entity and a second entity that transact in the transactional system;
- determining the states and the transitions between the states used by the first entity;
- determining the states and the transitions between the states used by the second entity;
- determining a required state in the plurality of states, wherein the required state is not used by the first entity but is used by the second entity;
- determining a required transition between the states in the plurality of transitions between the states, wherein the required transition between the states is not used by the first entity but is used by the second entity;
- determining a required data item of the required transition between the states; and
- defining a handler to handle the required data item, the handler used to enable transactions between the first entity and the second entity in the transactional system.
16. The computer programming product of claim 15, wherein the first entity is a plurality of pre-existing entities that transact in the transactional system and the second entity is a new entity to be added to the transactional system.
17. The computer programming product of claim 15, wherein the required state is a plurality of required states, the required transition between the states is a plurality of required transitions between the states, and the required data item is a plurality of required data items of the plurality of required transitions between the states, wherein defining a handler to handle the required data item comprises:
- defining a plurality of handlers to handle the plurality of required data items.
18. The computer programming product of claim 15, wherein a first transition between the states and a second transition between the states have the same data item.
19. The computer programming product of claim 15, wherein the transactional system further comprises a plurality of data enrichment rules, further comprising:
- identifying at least one of the data enrichment rules to provide the required date item; and
- wherein the transactional system further comprises a plurality of validation rules for validating at least one of the transitions between the states.
20. The computer programming product of claim 15, wherein the handler comprises:
- an application programming interface function or an input from a user interface component.
Type: Application
Filed: Apr 26, 2023
Publication Date: Oct 26, 2023
Inventors: Walter Hughes Lindsay (Phoenix, AZ), Matthew Charles Catlin (Thornton-Cleveleys), Robert Ernest Greenhalgh (Little Lever)
Application Number: 18/307,737
