WO 2004/044696 A3 ???! 1? »? 1«? 11? 11ß1 ?? 1? Declaration under Rule 4.17: (88) Date of publication of the International search report:- ofimehtorsh¡p (R¡de 4.17 (iv)) for US only 13 Jannaiy 2005 Fortwoter codes and other abbrevialions, referto the "Guid-Published: ance Notes on Codes and Abbreviations" appearing at the begin- - wíift iniemational search repon No ofeach regular issue of the PCI Gazette.
A SYSTEM AND PROCEDURE FOR ELECTRONIC SUBROGATION, WORK FLOW MANAGEMENT BETWEEN ORGANIZATIONS, TRANSACTION PROCESSING BETWEEN ORGANIZATIONS AND USER INTERACTIONS BASED ON AN OPTIMIZED COMPUTER NETWORKCROSS REFERENCE This request refers to provisional application number 60 / 425,058, filed on November 8, 2002, entitled "Electronic subrogation system and procedure" and provisional application number 60 / 425,670 filed on November 12, 2002, entitled "System and Field of the Invention The invention relates generally to an intelligent electronic subrogation network ("ESN") that automates the work flow between organizations, the work flow and the collaboration between organizations for the subrogation of insurances. The invention also relates to a novel system architecture and procedure that includes a workflow management system, a transaction processing system between organizations and a unique mechanism for optimizing and enriching a user based interaction. in the computer network within said system. to invention, at least2at the beginning, referring to the operation of an electronic subrogation network. BACKGROUND OF THE INVENTION During the 1980s and 1990s, several commercial transaction processing systems focused on the integration of business processes and data that existed within an organization (ie, within an organization). These systems cover a wide selection of commercial applications, of diverse complexities, including transmission / production scheduling, request processing, human resource management, financial accounting, sales management, etc. Commercial examples of such a system include offers from SAP, Oracle and PeopleSoft. The organizations that successfully implemented said systems obtained reduced costs, greater efficiency and greater competitiveness. With systems within organizations running, these organizations now seek to integrate business procedures, as well as data that exists between commercial partner organizations (ie, between organizations). Currently, most commercial transactions between organizations occur using paper documents as the primary means of exchange. This process is characterized by a high degree of3manual processing and long transaction cycle times causing high costs, errors and a lot of inefficiency. In contrast, the automation of inter-organizational processing systems has shown important benefits including increased efficiency, reduced costs, reduced transaction cycle times and greatly improved management information. For example, within many industries, there are several opportunities to automate the processing of commercial transactions between organizations, for example, insurance, manufacturing, health care, banking, etc. Within the insurance industry, there is an opportunity like this related to subrogation. Subrogation in insurance is defined as the process by which an insurance company (the claimant) seeks reimbursement from another company or person (counterpart) for a claim that has already been paid. For more information related to subrogation, refer to the detailed description below. Within most insurance companies, the subrogation function is not automated. Many of the larger companies have implemented a rudimentary classification system to identify subrogation, however, very few have implemented automation4for the subrogation workflow between companies and throughout the company. Manual and document processes still dominate the commercial practices of subrogation currently in use. Therefore, there is a need in the market for an automated system with the following unique capabilities for the processing of commercial transactions between organizations: 1) a centralized network center (based on computer networks) that facilitates the interconnection of several organizations and eliminates the proliferation of point-to-point interfaces, 2) an inter-organizational workflow management system that provides a common structure for managing the status of all transactions within the system, 3) an inter-organizational transaction processing component that support to multiple organizations and their distinctive relationship with each transaction and at the same time ensure the security and privacy of the organization's data; 4) a unified data model mechanism that allows the exchange of common data elements while supporting the requirements specific interfaces of the organization, and 5) gives application-specific and functionality specific to the types of business transactions that are under processing. Additionally, within the insurance industry,5An inter-organization system is needed for subrogation claims. Such a system would provide application-specific data and unique functions to the workflow of insurance subrogation. Summary of the Invention The electronic subrogation network (ESN) is a virtual reference center for subrogation claims designed to eliminate inefficiencies and manual tasks in subrogation processing. By using the ESN, the plaintiffs can issue subrogation claims electronically to the counterparts. The electronic folder of the ESN, supports structured and unstructured data, so that the parties involved can share the information of the claim as well as any supporting documents. Although the primary parts of the subrogation claim often involve insurance companies, the additional parties can also take part in this business transaction (eg, bargaining organizations, collection organizations, lawyers, etc.). The ESN has the unique ability to provide a common workflow and collaborative procedures for subrogation that encompasses multiple diverse organizations, ie, inter-organizational workflow and transaction processing.6The ESN provides functions to manage the flow of work between companies and the collaboration between them. The ESN manages the workflow between the parties involved through a workflow model based on the state that ensures the consistency of the workflow between multiple parties. The counterparts can create rules in the ESN to send the demand for subrogation to the appropriate file managers. All parties involved can create business rules in the ESN based on the business practices of each company, which are used to audit all files and identify the conditions of exception. Several parties can collaborate and negotiate online through the ESN. The ESN provides functions for the automatic conventions of subrogation claims, without the intervention of the man, when the files of the claims pass all the audits of the commercial rules of the parties and the responsibility calls correspond. The ESN reviews the files with the comparative negligence regulations of each state and, when appropriate, automatically generates counterclaims that are linked to the original file. Any party using the ESN can assign any file to a third party, for example, a negotiation firm, a collection firm, outside attorneys, service providers, etc.7The ESN provides network payment functions. Payments can be reimbursed bilaterally or multilaterally where the ESN will monitor the expiration of payments between two or more parties in a defined period and then issue an alert to the parties that must make the payment. In addition, the ESN provides all parties with reconciliation and file location information. All ESN members will have online access to complete administration of reporting, including reports from the complainant and the counterpart. In addition, the ESN provides a reference function so that members can compare various aspects of their performance as a claimant or counterpart with the industry. The ESN provides elaborate workflow between organizations, collaboration and transaction processing capabilities. In doing so, the ESN is based on a platform of central programming programs and systems consisting of several generic technologies that include a subsystem of workflow between organizations, the transaction processing system between organizations and the JView ™ subsystem. The workflow subsystem between organizations is designed to meet workflow requirements both among the8organizations as within them. Use a series of workflow tables (data structures) and a unique workflow algorithm to perform all workflow management operations. The workflow tables are essentially a set of finite state machines (FSM), which define a closed loop system for the workflow related to a commercial procedure. The workflow subsystem manages the status of the workflow between organizations, the status of the workflow within an organization, the ownership of the next action in a file, the navigation of functions that can be performed, and the status of the file. The inter-organization transaction processing system provides the structure for a central processing network that handles business transactions between organizations. This structure isolates member organizations from each other, supports the exchange of structured and unstructured information, supports transactions and the workflow of multiple parties, as well as providing extensive data security and privacy for each organization. This system consists of four main areas, Interface Subsystem, Transaction Processing Level (TLP), System Services, and Application Logic. The Interface Subsystem supports the requirements of the single interface from any source9determined the origin of the transaction. By doing so, the interface subsystem supports the origin of the transactions of the automated systems (using electronic messaging interfaces) or interactive users (using interfaces based on computer networks). The Transaction Processing Level is responsible for coordinating the processing of all transaction requests within the system. System services provide common components and services for blocking and booking, object graphical services, business rules and alert management, workflow management, security administration, individual or team property, external notifications, instant services, development of reports and document management. The level of application logic provides the system with the application-specific functionality that it requires for a given vertical business process. This level consists of the unified data model, a mechanism to organize and model the commercial information specific to the subrogation, the logic of the application related to the model, the logic of the application related to the transaction and the configuration. The JView ™ subsystem provides a system and procedure to optimize and enrich the interaction between organizations. Importantly, it improves time10system response by downloading the generation of HTML to the client system and in this way substantially reduces the processing performed on the server. It reduces the size of the messages transmitted between the search engine and the server of the computer network, thus substantially reducing the required communication bandwidth. Provides an enriched set of local functions (performed on the client system) that eliminates requests from the server. This additionally reduces the processing load on the server and greatly improves the responsiveness of the system in general. Siteview Jview ™ fully utilizes existing search engine standards in computer networks, thus maintaining compatibility with existing client search engines (ie, supports a real thin client deployment and does not use special search engine extensions, for example, add-ons of the search engine, Java language applications, or ActiveX controls). By using this core technology, the combination of commercial functionality specific to ESN subrogation and advanced technology provides many unique benefits for the insurance industry. The benefits of the electronic subrogation network include making the subrogation workflow more efficient within the company andelevenbetween companies; reduce the amount of handling of subrogation documents as well as their transactions; improve the productivity of both the personnel involved in the subrogation (plaintiff) and the staff of the claims office (counterpart), by eliminating many manual tasks, reducing the cycle time of subrogation claims; Increase subrogation recoveries through better allocation of resources and automatic responses to claims; reduce the costs of loss of claims through the electronic audit of subrogation files; improve customer satisfaction by accelerating deductible refunds; reduce payment handling expenses in addition to providing valuable management information. BRIEF DESCRIPTION OF THE FIGURES The characteristics and the inventive aspects of the present invention will be evident upon reading the following detailed description and the drawings of which a brief description is presented: Figure 1 shows several interfaces with the users that can be implemented in the operation of an ESN in accordance with this invention. Figure 2 shows a block diagram of various modules / subsystems that can be included in a12ESN formed in accordance with the teachings of the present invention. Figure 3 shows a schematic and workflow process of how the initial demand can be presented to the ESN shown in Figure 2. Figure 4 illustrates a workflow process that shows the way in which a shared electronic folder and an audit trail can be created for the files that are hosted in the ESN shown in figure 2. Figure 5 shows a schematic process and the workflow for transferring electronic and digital documents in the ESN and to scan printed documents in the ESN.
Figure 6 shows a schematic process of a workflow of an on-demand network routing for the ESN shown in Figure 2. Figure 7 shows a schematic view of an out-of-network demand routing and a process of workflow for the ESN shown in Figure 2. Figure 8 shows a response module from a non-responding party and a workflow process to be used with the ESN. Figure 9 shows a module of response options and a workflow process adapted for use with the ESN shown in Figure 2.13Figure 10 shows an online trading module and a workflow process adapted for use with the ESN shown in Figure 2. Figure 11 shows a module of agreements and automatic approval / online negotiation and a workflow process adapted for use with the ESN shown in Figure 2. Figure 12 shows the workflow process for an automatic / electronic rejection feature adapted for use with the ESN shown in Figure 2. Figure 13 shows an automatic convention module and a process of workflow adapted for use with the ESN shown in Figure 2. Figure 14 shows an automatic counter-demand module and a workflow process adapted for use with the ESN shown in Figure 2. Figure 15 shows an allocation module (arbitrator) and a workflow process adapted for use with the ESN shown in Figure 2. Figure 16 shows an allocation module (to the vendors) and a workflow process adapted for use with the ESN shown in Figure 2. Figure 17 shows a manual payment module and a workflow process adapted for use with the ESN14shown in Figure 2. Figure 18 shows an electronic payment module and a workflow process adapted for use with the ESN shown in Figure 1. Figure 19 shows a network connection module for the subrogation payment and the workflow process adapted for use with the ESN shown in Figure 2. Figure 20 shows a unified data model (module) adapted for use with the ESN shown in Figure 2. Figure 21 is a diagram showing an STM object hierarchy in the Jview ™ subsystem. Figure 22 shows the concept of various parties and their (relationship) with a transactional folder (for example, an insurance subrogation transaction) within the inter-organizational workflow management system. Figure 23 shows an example of a "form" Jview ™. Figure 24 shows an example of a "form" ofJview ™. Figure 25 is a relationship diagram with the entity of the main data entities within the inter-organizational workflow management system. Figure 26 is a diagram showing thefifteensystem architecture for processing transactions between organizations. Figure 27 is a diagram showing the different layers of the architecture of the application structure for processing transactions between organizations; and Figure 28 is a diagram showing a typical transaction processing architecture based on computer networks and the relationship of the structure of the application (for the processing of transactions between organizations) within this architecture. Detailed Description of the Invention BACKGROUND - Electronic Subrogation Network (ESN) Subrogation Defined Subrogation of insurance is defined as the process by which an insurance company (plaintiff) seeks reimbursement from another company (counterpart) or person for a claim that has already been paid. Examples of subrogation include: Sandra's vehicle stops at a stop sign, Pedro's vehicle hits her from behind; Sandra's car is damaged and she has some injuries. Sandra submits a claim to her car insurance company. His insurance company pays Sandra damages and injuries, but believes that Pedro was the culprit of the16accident. The insurance company of Sandra (plaintiff) will then subrogate against the insurance company of Pedro (counterpart) to recover the cost of the claim he paid to Sandra. Tom's house burns down as a result of a fire in the store next door. Tom files a claim with the insurance company of the owner of his house. Tom's insurance company pays the damages caused to Tom, but believes that the store is responsible for causing the fire. Tom's insurance company then subrogates against the store's insurance company the amount of the claim he paid. Daniel loses control of his sports car and hits a tree after his tires are broken. Daniel files a claim with his car insurance company who pays for these damages and then submits a subrogation against the car manufacturer and / or the tire manufacturer to recover the cost of the claim. Jane's vehicle is hit by a motorist who does not have insurance, Jane files a lawsuit with her auto insurance company. His insurance company pays the damage to Jane, but believes that Bob was responsible for the accident. Jane's insurance company files a subrogation against Bob to pay the cost of the17demand. Current Subrogation Process The current subrogation is done manually, it is a process that requires many documents. Some insurers have information systems that help identify the opportunities for subrogation, but very few present an electronic communication with other insurers. The process of subrogation begins when the demand is first reported to the insurer through the insured. During the lawsuit investigation process, the insurer determines if there is an opportunity for subrogation. If a claim is "classified" with an opportunity for subrogation, the file is transferred to the subrogation office (larger insurers have specialized units for subrogation, while smaller insurers typically handle the subrogation of their offices in the field with demand adjusters). Once the claim is paid, the subrogation office prepares a subrogation file consisting of a demand letter and some supporting documents. The demand letter contains the basic information about the demand, for example, the quantity demanded, the number of demand, etc., as well as the liability that the demanding insurer considers18which belongs to the insurer of the counterparty. The subrogation file is then sent by mail to the counter insurer. Support documents usually include a copy of the estimate of the damage that was paid for the claim, some proof of payment and copies of any associated invoices (the car rental bill, for example). However, supporting documents can include many other types of documents that include police reports, photographs, vehicle valuation reports, witness statements, etc. Once assembled, the subrogation file (called "demand") is sent by mail to the counterpart insurer. Subrogation departments often have difficulty determining where to send subrogation claims, especially when the counterpart is a large insurer with hundreds or thousands of claims offices. As a result, subrogation demands are often sent to the wrong location. Typically, insurers receive and handle subrogation files in their field offices. These claims are known as third party claims. If a subrogation claim is sent to the wrong office, you are given a new route to the appropriate office. This can take weeks or even months in the process. Once the demand finally reaches the19Adequate file manager (usually a claims adjuster), the file manager compares the facts of the complaint with the facts of the claim he has in his file. Usually, the insurer of the insured counterparty will have already filed a claim by the time the insurer of the counterparty receives the demand for subrogation. The claim adjuster of the counterpart's insurer then investigates the claim and determines whether the demand of the claimant insurer is justifiable. Often this includes obtaining additional documentation from the claimant insurer including photos of damages, witness statements, etc. If the adjuster agrees with the claim, then authorizes payment of the claim. The majority of automobile subrogation files are established in this manner, that is, without negotiation. If you do not agree with the claim, then deny the claim or negotiate the claim with the claimant insurer. Typically, negotiation is done over the phone and the details of the negotiation are usually not recorded. If the agreement is finally reached, the counterparty pays the agreed amount. If an agreement is not reached, then the file will be arbitrated or litigated. If the responsible party is an uninsured driver (U), most insurers send the collection effort to atwentycollection agency. Most of the principal owners and insurers are members of arbitration networks, nonprofit organizations created to arbitrate subrogation claims among insurers. Members of the arbitration networks always send their arbitration files to the arbitration service of the arbitration network. Arbitration networks charge a fee to file and the arbitration process usually requires about 90 days. If either of the parties, the claimant insurer or the counterpart's insurer is not a member of the arbitration network, then the file will be litigated. Payment among insurers is also inefficient. Typically, checks are cut for each and every file among insurers. This can result in hundreds or thousands of checks flowing daily in both directions between the major insurers. Once the payment is collected, the claimant insurer integrates the deductible paid to the insured, again with the check. Due in large part to all the paperwork and manual processes, the cycle of subrogation is often very long. A typical cycle for an average car subrogation file is 90 to 120 days. The cycle can betwenty-onemuch larger for files that go to arbitration or litigation, claims with total loss and claims of uninsured drivers. Information on workflow management in subrogation (as is typical of any paper-based process) is usually scarce. Some insurers have limited information in the process of the demand side and very few insurers, have significant management information on the side of the counterparty. Types of Subrogation Physical Damages to the Automobile Claims for physical damage to an automobile ("APD") are claims associated with physical damage to a vehicle of an insured, commonly due to a collision. The vehicle can be repairable or it can be a total loss. Other claims that fall into this category include stolen vehicles and vandalism. Medical Payments / Personal Injury Protection Claims for medical payments and personal injury protection are the result of a person's injuries or illness that are covered by an insurance policy. Claims for medical payments / personal injury protection include injuries that are the result of a collision between vehicles.22Property Claims for property are the result of damage to personal property or property. Some property subrogation claims can be simple, while others can be very long and complex for negotiation. Volumes are much lower than car claims, but property subrogation is a workflow very similar to physical damage to a car. Product liability Claims for product liability are the result of damage caused by a defect in a product. Subrogation claims for product liability usually involve complex negotiations and their volume is low. Compensation of workers Compensation claims for workers are the result of injuries that occur during working hours and when performing work tasks. Some workers' compensation subrogation claims may be simple, while others may be complex in their negotiation. Health insurance As in claims for property and for2. 3liability, health insurance claims are also subrogated when the illness or injury has been caused by the negligence of another party. Subrogation Trends Insurers began to dedicate personnel to subrogation in the mid-1990s. Historically, claims adjusters in the field handled subrogation claims. When larger insurers began to understand the importance and potential size of the dollar recovery of subrogation demand, they created special subrogation centers (usually centralized or regionalized) dedicated to recovering subrogation. The subrogation function is not very automated in general. Many of the largest insurers have implemented a rudimentary classification system to identify a subrogation, but very few have implemented an automation for a workflow in subrogation throughout the company. Paperwork and manual processes still dominate subrogation processes. A few years ago, the industry recognized the need to improve the communication of subrogation files between companies. Through the National Standardization Institute of the United States ("ANSI"), the industry formed a standardization committee that completed a24EDI X12 specification for subrogation in February 2001. Normalization has not been implemented in any of the insurers. Normalization defines business cases for only a subset of real-world business cases. further, assumes that all insurers support standardization and implement their own software logic and back end programming systems to interpret the data and execute their workflow. Thus, there is a need for an electronic subrogation system and process for all types of insurance claims, including those identified under the section entitled "types of subrogation." The benefits of the electronic subrogation network ("ESN") of the present invention include: making the subrogation workflow more efficient within the company and between the companies; reduce the amount of paperwork handling of subrogation documents and transactions; improve the productivity of both parties, the applicant and the counterpart; reduce the cycle of subrogation claims; increase the recovery of subrogation through automatic counterclaims; reduce the costs of loss of claims through the electronic audit of subrogation files; improve customer satisfaction by accelerating reimbursements of deductibles; reduce payment for managing expenses and improve management information25valuable DETAILED DESCRIPTION - Electronic Subrogation Network (ESN) The detailed description below can be presented in terms of program, data structures or procedures that run on a computer or computer network. These descriptions and process representations are the means used by those skilled in the art that most effectively represent the substance of their work for others skilled in the art. As mentioned above, the ESN acts as an electronic compensation for the demands and responses of the subrogation. The ESN is a system and process implemented in an Internet-based computer that allows insurers to interact with each other in addition to interacting with other parties (arbitrators, attorneys, collection agents, etc.) involved in the subrogation process. With the ESN, parties can send and receive electronic subrogation requests, attach supporting documents (estimates, photographs, police reports, etc.), negotiate online, establish files automatically, assign files to arbitrators and vendors, view and transferring reports online, automatically auditing files, receiving alerts and electronic notifications and much more. In addition, the ESN26includes the ability to send and receive electronic payments and due dates of net payments. With the online reports of the ESN, the parties have access to powerful management information in both the subrogation demands issued and in the third party claims received. Because ESN is based on computer networks, information can be accessed at any time, anywhere a user has access to the Internet, and implementation is often simple and straightforward, since it does not require the installation of a computer. programs and programming systems. If necessary, the ESN can directly interface with the claim systems in virtually any format in a batch mode or in real time. The ESN refers to a system and process based onInternet or in another network for electronic management and the establishment of inter-company subrogation transactions. The ESN provides a system to facilitate subrogation transactions and workflow among all parties involved in subrogation. As can be seen in Figure 2, the ESN can include data translation, collaboration, workflow, demand routing, security, commercial functions, business rules, electronic payments, subrogation folder reports and modules or connectivity subsystems. . Each27system or module, one or more of which can be used to process a demand, can include programs and programming systems, physical components of computation or both that facilitate the process of a demand. The electronic subrogation network ("ESN"), as indicated in figure 2, is a method for processing insurance subrogation claims through an electronic network. As best seen in Figure 2, the ESN contains a variety of components and processes: Presentation of the Demand for Subrogation and Document Administration; Workflow of the Community of Subrogation;Routing of the Subrogation Claim; Subrogation Monitoring Actions; Commercial Rules and Alerts of Subrogation; Subrogation Advisor; Valuation of the Subrogation Vehicle; Collaboration in Subrogation; Automatic Subrogation Agreement; Against Automatic Claims of Subrogation;Assignment of Subrogation to Third Parties; Management of Subrogation Payments; Payment Network of Subrogation; Preparation of Reports of the Administration of the28Subrogation; References of the Subrogation; and Model of Data Requested for Subrogation. Presentation of the information on the demand for subrogation and document management As best seen in Figure 3, the ESN provides a method for submitting subrogation claims in a manner that provides a mechanism for transmitting unstructured structured claim information (claims data from the claims system) (documents and supporting images) and provides a mechanism to digitize documents of support on paper. Then, in the operation, the ESN provides a process and a system to perform the following operations: manually enter the information of subrogation demands in the ESN; transfer the file of the subrogation claim records in the ESN; transmit files of subrogation demand in the ESN through an electronic interface. The transfer function of a file allows a party to use the file transfer capabilities within the ESN ASP to manually transfer a transaction file for processing. This technique can be used with any file format. Offers a29excellent security because it uses the same HTTPS transport as all other ASP-based interactive functions. Of all the interface techniques, the least amount of configuration and establishment is required. To use the transfer and files, the party creates a file of the subrogation claim records from its claim or subrogation system and then transfers the file by selecting a button. The ESN then automatically correlates each record to the requested data model. The ESN supports both batch and transaction interfaces. The batch interface allows an insurer to automatically send / receive a batch of transaction files for / from the ESN on a regular basis. Typically, a file transfer protocol (for example, FTP, etc.) is used. File transfer is automated and does not require any manual processing. The transaction interface allows a party to automatically send / receive individual transactions for / from the ESN in a real-time per event manner. This interface is completely automated and does not require any manual processing. This type of interface is used where information is needed in real time. As best seen in Figure 4, once the ESN receives a record of the demand for subrogation, the ESN30creates an electronic subrogation folder, which may contain structured and unstructured information, as well as a historical file. The historical file is an event file with a time label for all the actions that are carried out in the folder. The historical file contains an event log with a time label that follows the documents affected by the event and the user ID for the user who performed the action that created the event. The historical file provides both the complainant and the counterparty with a complete audit trail. Through electronic interfaces or file transfers, the ESN can send and receive messages in many formats. Including files, EDI x12, XML or ASCII. The ESN also supports the ANSI X12N272 subrogation lawsuit and counterclaim. As can best be seen in Figure 5, the unstructured support documents can be transferred in the ESN generally with any of the following techniques. When claims are filed electronically, the electronic message (containing the demand data) can specify the IRL (Internet location) for one or more related documents. Upon receiving the electronic message, the ESN automatically retrieves the31specified document of the specified URL. This capability refers to the sender making all related documents available on a server that can be accessed through the Internet. Secure access to these documents can be provided in various ways (for example, VPN, secure system access, digital certificates on the client side, etc.). Users attach electronic support documents using the function to attach directly to the ESN. Users search among the documents they wish to attach, select the document, select the document, select the type of document from a menu that is displayed, provide a title and / or description of the document, select the parties that have access to the document, and then select a button to attach the documents to the folder. To use this function, the supporting document must be available as a file on a local machine or on an available network server. The supporting documents can have some of the following formats:32The ESN then converts the source document in its original format to a standard format for universal viewing. The documents are converted into the following formats: Documents-viewer / Adobe Acrobat add-on. Graphics-viewer / Adobe Acrobat add-on. Audio-any standard player / MP3 complement (for example Microsoft Media Player). Video-any standard MPEG player / add-on (for example, Microsoft Media Player).33Any paper documents can be sent to the ESN using a fax support. To use this support, the user must first use an "append quickly" function to select the type of document and then print a special cover page for faxing. This cover sheet is then placed at the top of the document that will be sent by fax. The document can then be faxed to the ESN. Upon receiving the fax, the ESN automatically digitizes the special cover (using an OCR) for the special codes in the information. When using this information, the system attaches the document to the appropriate demand folder. The ESN manages several versions of document support. Workflow of the community in subrogation The ESN manages the workflow between the parties(two or more) within the subrogation process in a way that provides a consistent workflow for collaboration between companies, provides real-time status information to all parties involved and activates a specific workflow per company based on in the events and exception conditions within the workflow. The specific workflow model of subrogation includes states of workflow among companies, transitions, conditions, status, indicators of3. 4action, etc. The company-specific workflow is also provided within the context of the community workflow. As can best be seen in Table 1, the ESN can support standard codes to represent the state of a demand at any point in the process (that is, the workflow of subrogation between standard companies). These standard codes establish the basis for consistent understanding and communication between the parties regarding the status of a particular claim. In this way, these codes represent the status of the subrogation file between parties in the ESN. Additionally, the ESN can be configured to allow the definition of the specific state codes of the parties (that is, the subrogation workflow within the company). These codes allow an organization to define additional workflow statuses that are specific to its business processes, while maintaining a standard process definition among organizations. Routing of subrogation claims The ESN routes the subrogation demands to the counterparts. A routing algorithm combines a specific index of the claimant and a heuristic algorithm to determine the counterparty. The data never really35they leave the ESN server, the routing is virtual, and the file manager receives notification of the demand in the ESN through an electronic notification (email, page, text message, etc.). If you receive a notification via email, then the ESN provides a URL link for the user to access the ESN and the appropriate demand file. As best seen in Figure 6, a counterpart that is a member of the ESN maintains routing rules in the ESN, so that the ESN can electronically route the incoming subrogation files to the office, group, or handler of adequate files. The ESN supports semi-automated routing and automated routing. With semiautomatic routing, the initial claim is routed to a counterpart coordinator ("enturador") at a central, regional, or claims office. By using the ESN, the router can view all incoming demands ("pending routing"). Using their internal claim system, routers can determine the claim number of the counterpart associated with the claim and the group or individual currently assigned to the file. The router then goes to the "route demand" function to update the demand with the additional information (for example, the claim number,36the percentage of responsibility, etc.), and transfer the demand to the correct group / individual within the organization of this part. After completing this function, the system now "queues up" this demand for the specified group / individual ("pending response"). With automatic routing, the counterparty transfers a "claim file" file to the ESN on a regular basis (eg daily). The claim index provides the summary information on a claim, which allows a search in the ESN to locate the claim. When the ESN receives an initial claim for this part, it can use the claim index to automatically route the claim to the right group / individual within the counterpart's organization. The claim index file can also be the basis for supporting automated agents within the ESN who can automatically review and respond to initial demands based on business rules. The ESN also provides a function to report for the first time on loss conditions where the ESN or counterparty can determine if the claim is the first loss report and automatically route the file to the counterparty loss notification unit. When the counterpart receives the initial claim, if the "applicant"37(as identified in the initial claim) is insured / covered by the counterparty, but there is no claim (within the counterparty's claim system) for the specified loss date, then this claim represents a first notice of loss. In this case, the counterpart first needs to establish a claim file (within its system) before processing this claim. To support this workflow, the system will place this demand in a special "first loss notification" state. In this way it allows the counterparty to easily identify and process all the incoming demands in this condition. With automated routing, this condition can be automatically identified by adding a policy container index. With semi-automated routing, the routing coordinator, who can be a human operator, can use the "first loss notification" (FNOL) function to move the demand to this state. The ESN also supports the ability to reassign a file to another file handler through the assignment function. This electronic routing function is available to parties that are members of the ESN. As best seen in Figure 7, a38counterpart who is not a member of the ESN will receive notification by email or fax about a demand for subrogation from the ESN. A user of the counterparty can select a link in an email to access the file of specific subrogation requests. Counterparts that are not members of the ESN can reassign files by transferring the ESN email notification to the system for the first time, the system presents a tutorial that provides a basic introduction to the ESN and familiarizes the user with the basic characteristics and It will be necessary for you to know in order to respond correctly to the demand issued. The plaintiffs have access to the online directory of the counterpart contacts outside the network, locations and email addresses. This directory is updated automatically when a demand is issued to a new contact outside the network and all the complaining parties can access it in the ESN. Follow-up actions for subrogation The ESN automatically establishes and activates follow-up actions for demanding users. As best seen in Figure 8, if a counterparty does not respond to the demand for subrogation, the claimant may send several reminders by email to a counterparty. A plaintiff party39you can define reminders of the specific tracking action by company in the ESN; For example, the ESN can issue reminders to the requesting users to contact a counterpart user if there is no response within a specific time frame defined by the complaining party. The ESN can issue alerts, reminders and the following actions either for 1) a grouped team of demanding users so that a given user in the cluster gets the file that requires the next action, or 2) an individual file manager. Rules and Commercial Alerts for Subrogation ESN models unique business practices for each member of the network and for managing exception conditions in the workflow in a manner that facilitates persistence between each member's business practice and workflow. In the net. The processing and functions performed by the ESN can be affected by various parameters specific to the parts and their configurations. Collectively, these configurations represent the "business rules" of a party and allow a party to customize the processing of the ESN to support the specific business processes of the party. The parties can define specific profiles of the global or commercial software and the commercial rules. For example, when the ESN processes a transaction determines,40the logic within the ESN refers to the "business rules" of the identified party and uses them to control the processing of the transaction. The ESN allows specific business rules for the parties to be broadly divided into a number of main categories as indicated below. Company rules Define the overall configuration for this part. Workflow rules Define the workflow specific to the part. Routing rules Define part-specific configurations for automated or semi-automated demand routing. These configurations are typically used to control the way in which the ESN routes an incoming demand within the organization of a part. Records audit rules Define the specific rules of the party for audits and record conditions. This includes the following groups: General - if the loss is total, the ransom is deducted. Specific to the plaintiff - for any response received, it is the recovery percentage lower than the minimum recovery percentage. Specific counterparty - amounts of damage41abnormal specified as the percentage compared to collision damage, ie, reimbursement for rent, towing, loss of use, etc. (for the limits of the amount of demand). The maximum tolerances for various amounts of damages (by limits of the amount of demand). Business Partner Rules Define the specific settings of the part that apply to one or more business events. A unique generic rule set can be established for all partners. In addition, a specific set can be established for a particular business partner. In this case, these settings will override any generic settings for this specific partner. The following rules can also be included: the annexes required for the demands (by quantity limit of the demand) and require annexes for the claims based on each code of claimed coverage. Members can configure specific business rules by the company. All files are audited based on the business rules of all parties involved in the transaction. Alerts are triggered by exception conditions or violations of business rules based on the parameters of multiple parties (defined by ALL parties that have42currently accessing the folder)For example, a counterparty may receive an alert based on the parameters of the claimant. A particular party can customize the alerts. This feature allows a party to determine the conditions of the specific exceptions that generate an alert. When a file is displayed, if there is any alert, an "alert panel" is displayed inside the file. When acting on a file, if there are alerts or are detected recently, the user will receive the presentation of a warning message. To continue with the transaction, the user must explicitly annul this notice. In this case, the notices and the user are registered in the editorial. The following list illustrates the standard or generic alerts that are included in the ESN: File Audit Alerts - These alerts refer to the exception conditions that are detected based on the "file audit rules" defined for a party. Exception alerts for the business partner - These alerts refer to the exception conditions that are detected based on the "business partner rules" defined for a party. Comparative negligence alerts - These alerts refer to exception conditions that are detected with43based on the comparative negligence laws of the state in which the loss occurred. For more information, see "Comparative Negligence Support" below. Statutes of limitation alerts - These alerts refer to the exception conditions that are detected based on the statute of limitation laws for the applicable state. Subrogation Advisor - The ESN evaluates the best course of action within the subrogation process in order to improve the performance of subrogation, increase recoveries and lower costs. The ESN can evaluate, for example, the cost-benefit of continuing a lawsuit and / or continuing a particular line of action, for example, continuing litigation, etc. Valuation of a subrogation vehicle The ESN evaluates the validity of a subrogation claim from a third party. For example, electronic audits for certain file conditions can be based on parameters that are configurable from the claimant, the counterparty and the value of the vehicle, for example, the recovery of the total loss, the conditions of loss of use, etc. Subrogation Collaboration The ESN provides a method for multiple parties including the complaining party and the counterpart44Collaborate interactively. As best seen in Figure 9, a counterparty can accept (agree to pay), rebut (negotiate) or refuse (refuse to pay) a demand for subrogation. As best seen in Figure 10, a counterpart can prepare a counteroffer that may include a response to the percentage of liability and / or amounts of damage (for example, amount of collision damage, amount of rent reimbursement). , etc.). a plaintiff may define a minimum acceptable counteroffer on a file-by-file basis and the ESN issues an alert to the plaintiff if a counteroffer is below the plaintiff's minimum. As best seen in Figure 11, a claimant can define business rules regarding minimum acceptable counteroffers that include the percentage of liability, amounts of damage, and / or total demand and the ESN can automatically approve counteroffers if the business rules of the plaintiff are met. As best seen in Figure 12, a counterparty can deny a claim and provide standard denial codes in response to the claimant. Commercial functions The ESN provides commercial functions that support the workflow of subrogation. In addition to theFour. FiveStandard functions that are provided in Table 2, the system allows a part to define custom functions that are specific to the process and commercial work flow. These custom functions can be defined to control the data display modification. Automatic Subrogation Establishment As best seen in Figure 13, the ESN provides a method for establishing subrogation claims between the parties automatically with little or no human intervention, by eliminating many manual tasks, and reducing the cycle of subrogation files. The ESN works to establish files electronically if the file passes the audits of the commercial rules of both parties and the calls of responsibility of both parties (the percentage of responsibility assigned by each party to each insured party) correspond or overlap. The plaintiff's liability call is provided at the filing of the initial claim. The call of the counterpart's responsibility is read through the ESN through an electronic interface with the counterparty's claim system or through a claim index provided by the counterparty. "Anti-gambling" capabilities prevent counterparts from guessing the business rules of the plaintiffs46and / or responsibility calls. Automatic subrogation counterclaims As best seen in Figure 14, the ESN can create counterclaims when it is in compliance with regulation, that is, it is configured to include the relevant laws of the state where the loss occurred, so that helps reduce counterclaim opportunities for loss, and helps increase the recovery of subrogation, helps improve the productivity of both the claimant and the counterpart by eliminating many manual tasks, and helps reduce cycle time for the Subrogation files. When the original claim is established, the ESN can audit the safety percentage and comparative negligence regulations of the appropriate insurance state department then, when the initial claim is established at a less than 100% liability percentage for the counterparty and meets With the comparative negligence regulations of the loss status, a counterclaim is automatically prepared for the counterpart against the claimant for a fair action related to liability. For example, if the loss was made in a pure comparative state and both parties agreed on an 80% responsibility for the47Counterpart in the initial claim, the ESN prepares a counterclaim for the counterpart for the responsibility of 20% against the counterparty. The counterclaims are linked to the original demand. The ESN alerts the complainant about audits of business rules that are being violated. With the ESN, users can create counterclaims in one of two ways; 1) using a "create counterclaim" action, or 2) issue a new claim where the claimant and the counterparty number the links to an existing claim (in an inverse relationship). Create a counterclaim Once the counterparty has accepted a claim, the system determines whether there is an opportunity for a counterclaim for this claim (depending on the percentage of liability and the comparative negligence laws of the specific state that apply to this claim). In the processing of the "accept" function for a demand, the system analyzes these conditions. If this demand has the opportunity of a counterclaim, then the system automatically indicates it. A specific form of counterpart "counter-claim opportunities" is provided and this lists all the claims that are candidates to issue a48counterclaim To issue a counterclaim, the counterparty selects one of the demands of the "counter-claim opportunities" form. When the form is displayed, a new action is available "create counter demand". This action can be used to create a new demand document that is related to the initial demand. When this document is created (saved), the ESN automatically routes the counterclaim to the plaintiff who issued the initial claim. In doing so, both the initial claim and the counterclaim are related (that is, they refer to each other). Linking automatic counterclaim When two companies issue claims to each other (independently) for the same loss, at the point where the second claim is issued, the ESN recognizes the counterclaim's relationship and automatically relates the claims. This capacity handles the situation where both companies believe that the other is "responsible". In general, at any time that the ESN detects that two lawsuits have been issued between two companies (in which the numbers of demands of the plaintiff and the counterparty refer to each other); the system automatically "relates" these demands.49Once a counterclaim is identified, the user can easily move back and forth between the two claims by selecting the counterclaim link. From that moment and onwards, the collaboration capabilities of the counterclaim are exactly the same as for the initial claim. In addition, the ESN applies this background to the means of comparative negligence of the appropriate state and issues warning in the event that the ability of a party to issue or continue a counterclaim is affected. Additional forms are provided to enable the counterparty to administer the counterclaims that have been issued. Within each state, comparative negligence laws are defined, which govern the ability of a particular party to issue a counterclaim. When a claim is "accepted" by a counterparty, the ESN applies the comparative negligence laws of the state of the loss location. Based on these laws, if the demand is accepted, the ESN issues warnings to the user under the following situations: a counterclaim has not been issued, but acceptance of that demand avoids the issuance of a counterclaim; and a counterclaim has been issued, but the fiftyAcceptance of this lawsuit can "invalidate" the counterclaim that is currently "in negotiation." In this case, the system requires the user to cancel this warning so that the request is accepted. Main types of comparative negligence levies There are three main types of laws of negligence, pure comparative, modified comparative (49% and 50%) and none (ie, negligence of contribution). Below is a summary of how these laws affect the ability to issue claims and counterclaims. Pure comparison The responsible party can issue a counterclaim for any responsibility between 1 and 50%. Comparative modified 50% Unless both parties agree on a 50% liability, the responsible party can not issue a counterclaim. Comparative of modified 49% The responsible party can not issue a counterclaim. If both parties agree to a 50% liability, then neither party can issue a claim to the other.51None No subrogation is allowed. No party can file a claim. Allocation of Subrogation to Third Parties The ESN provides a method for assigning subrogation files to third parties, so that the productivity of both the claimant and the counterparty is improved, the time of the subrogation cycle is reduced and the time is provided. of consistent management. As best seen in Figure 15, a plaintiff can file an arbitration through the ESN. Once the plaintiff selects the arbitration function, the ESN electronically notifies the counterpart that the plaintiff is filing the request for an arbitration. This provides the counterparty with an additional opportunity to agree before joining the arbitration. The plaintiff can then electronically file arbitration at any time after sending the first notice to the counterparty. Through this multi-part support function, the ESN notifies the arbitrator that the claimant filed the arbitration and provides the arbitrator with a list of all the claims that have been filed for the arbitration. The arbitrator can then enter the hearing dates, case numbers and other information in the file.52The counterparty can review the arbitration by presenting online and presenting its response. Once the hearing is completed and the trial is granted, the arbitrator can notify both parties about this concession through the ESN. In this way, the ESN becomes an electronic "toolbox" for arbitration. The ESN is designed to enable controlled access to each "shared" subrogation folder for multiple parties. In doing so, each party typically has a specific "business relationship" for that folder (plaintiff, counterpart, arbitrator, etc.). The ESN explicitly defines these relationships; and for each relationship, the ESN controls explicitly the information that is observed inside the folder and the actions that can be carried out. For example, suppose that three parties are established in the ESN, the insurer Gordon, insurer Acmé and Arbco. If Gordon issues a claim for Acmé, then when the subrogation file for this lawsuit is created, the plaintiff will be Gordon (plaintiff's relationship) and the counterpart will be Acmé (counterparty's relationship). In this way, all Gordon users will have an access limit to the data and functions associated with the "claimant" relationship when they access this folder; All Acme users will have limited access to the data and53functions associated with the "counterpart" relationship when accessing this folder. Additionally, if Gordon files the file for arbitration, then his arbitrator (Arbco) will grant them access to the file. By doing so, all Arbco users will be limited to the data and functions associated with the "referees" relationship when they access this folder. Additionally, if Acmé files a suit with Gordon, then the applicant / counterparty relationships are exchanged for the specific subrogation folder. When a company is established in the ESN, all possible relationships for a given company are defined. In the previous example, both Gordon and Acme will be configured to support the "claimant" and "counterpart" relationships. However, Arbco will be configured only to support the "arbitrator" relationship (since it can not issue directly or respond to subrogation demands). As best seen in Figure 16, either a claimant or a counterparty can electronically assign a subrogation file to a vendor (for example, collection agencies, outside attorneys, service providers, etc.). through the ESN. When the claimant or the counterparty uses the assign function, the ESN automatically notifies the third party54part that there is a file that need to work. Depending on the interface of the third party, the ESN notifies through an email with a URN link or actually passes the information from the file through an interface to the third party system. The ESN also provides the ability for third parties to introduce status updates into the ESN. Subrogation payment management The ESN provides a method to manage payments between the parties involved in a subrogation claim in a way that improves the productivity of both the claimants and the counterparties by eliminating many manual tasks and decreasing the cost of handling payments . As best seen in Figure 17, after receiving payments from the counterparts, the claimants can enter payment information manually into the ESN or update files of the payment information (payment amounts, dates, claim numbers). associated, etc.) in the ESN. The ESN automatically closes the files where a payment has already been made in full. As best seen in Figure 18, EFT payments can be automatically activated upon acceptance by the counterparty, the ESN can generate a message to the counterparty's bank to55activating the EFT or the ESN can generate a message to the counterparty's system that in turn issues a message to a bank to activate the EFT (in the latter case, a counterpart system sends a confirmation message of the EFT back to the ESN). Subrogation payment network As best seen in Figure 19, the ESN provides a method for making a payment network between the parties involved in a subrogation claim so that the productivity of both the claimants and the plaintiffs is improved. of counterparts eliminating many manual steps and decreasing the cost of handling payments. The ESN works to track payments due and payments due in any period for any member and provides the information or automatically files a payment. Payments can be made in a network bilaterally (for example, between two parties as best seen in Figure 19) or multi-party (between one party and the ESN, which represents all the members that participate in the network service ). In the bilateral network, the ESN follows the payments due between two parties and sends a notification for the EFT to the party that has the payment balance at the end of any defined period of the two parties. For example, if part a and part b agree on56make network payments weekly, the ESN tracks the amount of all payments due between a and b in the week and all payments due between b and a week, determines which part owes more and issues a payment notification to the right part. In the multi-part network, the ESN puts together all payments and receipts with all the parties that participate in the network service for a specific part. The ESN then receives the payment from the party or pays the party depending on the balance. The parties can configure the ESN to define the specific network periods by part. The ESN provides session information and a reconciliation file to locate the network payments for each appropriate file. Subrogation Management Notification The ESN provides management information to network members in a way that improves the performance of subrogation for all parties and provides better management information for both subrogation managers and administrators of subrogation. the claims. The ESN provides two types of online, detailed and summary notification. For subrogation, various standard reports can be provided with the ESN (listed below). The ESN allows members to filter, classify and view management reports online. In addition to the standard reports, a57Member can define specialized reports that are specific to their business processes and work flow of the organization. For summary reports, the data can typically be aggregated along with the larger dimensions of time, geography, part, office, region, department, file / equipment manager, and status. Within these dimensions, the elements of the main data that can be summarized may include Total Demand in Dollars, Total Response in Dollars, Type of Recovery Percentage or other desired or pertinent data elements. For any of the data elements identified, the following summary statistics are generally supported: sum, average, heavy average, percentage, maximum, minimum, and count. However, other necessary statistics can also be supported.58I nformatio ns of the typical dem ationReports from the other partyPending files Total payments - amount of plaintiff paid to close coverage Total demands - amount demanded by plaintiff Number of files - number of files openedPaid files Total dollars paid - total dollars paid from all closed files Percent average payment - total dollars paid divided by total dollars demanded Number of files - total number of closed files Average cycle time - date of issue from demand until receipt of payment Time of the cycle Issuance of demand until the promise of payment (day) Issuance of demand until receipt of payment (day)59 Counterclaims Total dollars recovered - total dollars recovered from all closed files Average recovery percentage - total dollars recovered divided by the total dollar amount demanded Number of files - total number of files closed Average cycle time - date of issue of the counterclaim until the receipt of the paymentOperational reports Operational reports are designed to provide management information to system administrators. Standard reports include user profile reports and usage reports. Subrogation References The ESN provides a method for network members to seek references of best practices among the insurer industry so that they improve the performance of subrogation in all insurers and provide better management information for both the subrogation administrators as well as the claims administrators. The ESN allows members to refer to various parameters of their subrogation and / or claim operation against the aggregate industry based on the ESN database. For example, claimants can refer to their recovery relationships compared to the industry in a specific geographic area; the counterparts can make a reference to their payment relationships in60comparison with the industry for a specific geographic area. Model of requested data (UDM) for subrogation As best seen in Figure 20, the ESN provides a method for organizing and modeling the commercial information specific to subrogation in a way that provides consistent data for both the claimants and the counterparts and provides the translation of data from one format to another. The ESN provides entities, attributes and relationships specific to the subrogation workflow. The formats of the incoming data are translated from their source format to the UDM format. The UDM data formats are translated into outgoing data formats. Symantec translations are done in such a way that the meaning of any particular element is consistent and to one file to another.61TAB LA 1 States among the com pany (status) U n rchive of de m a nd o pe e n d this re la tion of the re ssu re s "once.
Differentiated State Description Differentiated State Indicates that the ESN has received the demand file (either electronically or through a file transfer of the claim) and that the ESN detected an error that prevents this demand from being issued (for example , has invalid data or is missing data). At this point, the claim is not issued to the counterparty and can only be seen by the claimant. Pending Routing Indicates that the claim was issued and assigned to a counterparty, but this party has not "routed" this claim within their organization. For counterparts that use semi-automated routing, this state is normal. For counterparts that use automated routing, this state is not common. First notice of loss Upon receipt of the claim, if the claim represents the "first pending notice of loss" to the counterparty, then this status indicates that the counterparty is in the process of establishing a claim file within its claims system. Answer pending Indicates that the claim has been routed to a file manager within the counterpart organization and waits for an initial response. Pending investigation Indicates that the claim was initially reviewed and the counterpart is doing the investigations. Counter offer issued Indicates that the counterparty reviewed the complaint and that it prepared a counteroffer for the complainant to consider. Approved counteroffer Indicates that the complainant reviewed the counteroffer and agrees to the terms of the counteroffer. Revised complaint issued Indicates that the complainant reviewed the counteroffer and that the complaint was reviewed for consideration by the counterparty. Challenge In the event that the claimant and counterparty do not agree to this claim, and if arbitration is not an option, then this state indicates that the claim is in litigation. At this point, the plaintiff physically assesses if it continues with the litigation. Denied Indicates that the counterpart rejected the claim Arbitration submission Indicates that the complainant wants to present this pending claim to arbitration and is currently in the process of preparing disagreements.62Aggregated States In addition to the differentiated states listed above, the workflow subsystem can include the following "aggregate states". An aggregate state is a set of two or more differentiated states. Standard forms are provided within the system to show files in a given aggregate state.
TABLE 2 Functions of the claimant The following exception lists the business functions that are typically specific to the claimant.63Function Description Create demand Manually create and issue a new demand Repair the damage Manually fix an incomplete or invalid claim that was created from a transferred demand file or an electronic messageDelete Manually deletes an incomplete or invalid claim that was created from a transferred claim file or an electronic message. Once a demand file has been issued, it can not be deleted. Review Review a claim. This function is typically used in response to a counteroffer that was received from a counterpart Approve Approve a counteroffer. This approval indicates the applicant's acceptance of the proposed counteroffer and allows the counterpart to now "accept" the claims as currently proposed in the counteroffer. Arbitrate Prepares to file a claim for arbitration. This function indicates to the counterpart that the claim is being prepared for arbitration. This action places the file in a state (pending arbitration request) that allows the plaintiff to prepare and attach its reasons for the arbitration Arbitration of the file It formally presents the demand for arbitration. This action implicitly guarantees the right of access of the "arbitrator" for the specific file in the arbitration service, in this way allows them to process the presentation of the arbitration. Supplement An amendment to a specific demand to include a "complement" Dispute Indicates that no agreement can be reached with the counterpart. This function is typically used to indicate that the claimant can not reach an agreement with the counterparty and that arbitration is not an option. At this point, the plaintiff decides whether to initiate a litigation with the file or closes it. It connects the file in a state (in controversy), which allows the plaintiff to easily identify all the records in this condition. Apply payment Registers a payment received for a file. This function applies the payment of the specific file. If the payment releases the outstanding balance of the file, then the file is automatically closedClose Close a file. This function is typically performed automatically when the final payment of the file is applied. When used manually, the user will need to specify a disposition of the file that represents the reason for the closure. Remission Sends a claim to another party. If a claim was made to a wrong counterparty, this function allows the claimant to reissue the claim to the appropriate counterparty. Reopen Reopen a file that has already been closed. This function allows a plaintiff to reopen a file that has already been closed for the purpose of submitting additional payment amounts for its recovery or to provide new information to the counterpart for reconsideration. Transfer The transfer of a claim file. This function uses demands to manually transfer a claim file to the ESN. When processing this command, the ESN ensures that the complete content of the file is stored in a satisfactory manner in the ESN, then the user is returned back to the user. In the second plane, the ESN processes to demand the file by creating a demand and issuing the demand to the appropriate party. A form is provided that enables the user to review the status of the post-transfer processing of the claim.64Transfer of payments Transfer of payments from a file. This function is used to manually transfer a payment file to the ESN. When processing this command, the ESN ensures that the complete contents of the file are successfully stored in the system. Then respond to the user. In the second plane, the ESN provides each payment in the file by applying the payment to a specific demand file. If the payment releases the outstanding balance of the file, it automatically closes the file. A form is provided to enable the user to review the status of the post-payment transfer processing. Functions of the speaker The following section lists the business functions that the answer is typically specified for the person making the response. In general, the main functions of the counterparty are available to network and off-network counterparts. When a function is only available to a network counterpart, it is indicated that way.
Accept Accept a demand. This function is used to accept the terms of demand as it currently occurs. In doing so, this represents a formal commitment of "promise to pay" by the counterpart. Counter offer Make a counter offer. This function is used by a counterparty to make a counter offer to a demand. When the counter offer is made, the counterparty may modify the percentage of responsibility or the amounts of payment. Research Indicates that the claim is investigated. This function changes the state of the file to "pending investigation". Submit a response Submit a response to the arbitration request. If, apart from the plaintiff arbitration filed the file for arbitration, the status of the file will change to "the arbitration (r)". At this time, the counterparty can prepare and attach its response to the request for arbitration. After the answer is appended, then this function is used to indicate that the answer has been presented. This function changes the status of the file to "in arbitration (A)" which indicates that it is now ready to be reviewed by the arbitrator to issue a final judgment. Reject Reject the demand. This function is used to indicate that the demand has been rejected. When a claim is rejected, the counterparty must select a rejection code from the ESN list of standard rejection codes. Create a counterclaim Create and issue a counterclaim. After accepting a claim, the ESN determines whether the counterparty can issue a counterclaim for subrogation. If so, then this function is used to create and issue the counterclaim. Route demand An incoming claim is routed within the counterpart organization. For counterparts that use semi-automated demand routing, this function is used to manually route / assign the demand to the appropriate team or individual.
First notification of Indicates that the claim represents the first notification of loss to the counterparty loss. This function changes the status of the file to "first notice of pending loss" and allows the counterparty to establish a claim presentation for the first time within its claims system.65Referee Functions The following table lists the business functions that are typically specific to a referee.
Common Functions The following table lists the business functions that are not specific to a particular relationship and can be shared by all relationships (unless specifically observed). Where a function is only available to a networked party, it is indicated that way.66During the middle of the late 1990s, the commercial use of the Internet emerged and flourished due in large part to the emergence of easy-to-use search engine technology (eg, Mosaic, Netscape, Internet Explorer, etc.) - This movement promoted the large-scale implementation of systems based on computer networks (network servers67computing) to support the growing number of users who rely on search engines. A key to this movement was the definition of message format standards (ie, HTML) that all search engines will support. The initial computer network servers were used to provide statistical content by transmitting only static computer network pages (containing HTML) in a search engine. By using this approach, the sites of the computer networks were created by developing sets of interrelated computer network pages that were linked together. Because the use of the Internet expanded, it became necessary for these servers to deliver dynamic content (for example, a page with the current status of an application, a page with the actual arrival time of a flight, etc.). The dynamic content requires that the server dynamically build the information for each request of the search engine. In doing so, the server uses a logic to analyze the requested request, retrieves the information from the necessary data source and dynamically builds the page of the computer network containing HTML (ie HTML generation) for the transmission to the search engine again. By using this approach, the search engine can not distinguish a static page from a68dynamic page Search engine technology also evolved in parallel with the technology of computer network servers. Most notably, the development of the ability to generate simple programs from standard search engines that allowed a user to interact with a page of computer networks without creating a new request to the server of the computer networks. This greatly improved user interaction and search engine response capabilities making it possible to build rich user interfaces (similar to a standard heavy client interface). This ability to generate simple programs was initially called JavaScript, but now it is formally named as EC AScript. Requirements and challenges Currently, most computer-based systems invest processing cycles to format dynamic content in an HTML format. This processing load can add up to 30 to 50% of the processing load of a typical server. In relation to the size of the information transmitted, the size of the HTML stream that contains that information is substantially larger (from 3 to 5x). This requires an additional communication bandwidth for the transition. By depending on69server for the generation of a page of computer networks requires an interaction of each user to be processed by the server of the computer networks, which causes an increased response time for various operations (for example, sorting a results page of certain elements, performing a data validation, performing calculations, etc.). The Jview ™ sub-system, described below, overcomes these limitations by 1) lightening the burden of generating HTML to the client system, thereby substantially reducing the processing performed on the server, 2) reducing the size of transmitted messages between the search engine and the computer network server, in this way it substantially reduces the required communication bandwidth, 3) it provides an enriched game of local functions (performed on the client system) that eliminates requests to the server; this further reduces the burden of server processing and greatly improves the overall respoeness of the system, and 4) fully utilizes existing computer network browser standards in this way maintains compatibility with existing client search engines (ie, Supports a real implementation of thin client and does not use any special exten of the search engine, for example, add-ons of the search engine,70Java applications or ActiveX controls). These capabilities are achieved with a JavaScript sub-system that runs inside the browser and a message structure compatible with HTML (a "Siteras transaction message" - ST) that is transmitted between the browser and the server. Within the client search engine, the Jview ™ subsystem consists of a series of JavaScript files. In response to an initial request from the computer network server, a small set of JavaScript files (that is, the core of the Jview ™ subsystem) are transferred to the client's browser. Once transferred, these files are placed in the buffer through the search engine (like other images or static pages). The additional JavaScript files transfer by modules when the various application interactions with the server need them (once transferred, these additional files are also placed in the buffer through the search engine). These JavaScript files provide the browser the ability to perform the following functions locally (without any additional interaction with the server): generation of HTML (the entire generation of HTML is done through the Jview ™ subsystem on the client); classification (which includes the classification of several columns); formatting of data (data, numbers, percentages, etc.); Dynamic HTML (for71example, expansion / contraction of panels / tab); print the format and preview; sample of the menu in hierarchical order; editing and syntactic validation; validation of the basic application; dynamic static domain management (that is, checking a value in a list of values); requires field verification; calculations of the application and measurement of the response time. Within the Jview ™ system, coding techniques from a single set of JavaScript are employed to keep the load of the response time for processing the Jview ™ subsystem to a minimum. Each interaction with the server consists of a standard HTTP request / response (the format of which is based on HTML 3.2 and contains a "Siteras transaction message" (STM)). The STM is a hierarchical structure of key value pairs (similar to an XML-based message in structure and content). Unlike an HTML message generated by a typical server, the STM contains mainly commercial data. In this way, the size of this message is greatly reduced. Essentially, this message structure is used to deliver a "data island" to the client browser, where the Jview ™ subsystem can operate generically. NOTE: There are two reasons why the Jview ™ subsystem uses the STM format instead of XML-1) the SPM maintains the72compatibility with a large set of search engines (many search engines do not support XML) and 2) XML is also very verbose and has the size of 1-2 x of the STM. Benefits of Jview ™ Below is a summary of the key features and benefits of the Jview ™ subsystem architecture. Together, these features allow the Jview ™ subsystem to focus on the performance and functionality of a heavy customer system, with the ease of use and manageability of a given customer system. Wide compatibility with search engines The system can work with any search engine that supports JavaScript V1.2, HTML 3.2 and CSS Level 1.0. This provides support for a large number of search engines, including previous versions of mainstream search engines (for example, 4.x series search engines from both Microsoft and Netscape). They do not use any of the specific characteristics of a certain type or version of search engine. Full thin client The system supports a true "thin client" architecture because it does not require or use any Java application, search engine add-on or active-X controls. Additionally, it does not use persistent "Cookies".73Exploits the processing power of the client system Many of the features of the Jview ™ subsystem were created to use the local processing power of the client machine. This greatly improves the responsiveness of the system, reduces the number of interactions with the server and frees the server from having to perform this processing. The performance of the Jview ™ subsystem has been optimized to present as little impact as possible on response time to / from the server. In general, Jview ™ subsystem processing adds less than one second to the response time to any interaction with the server. Additionally, because the processing power of client systems continues to improve response time due to the fact that Jview ™ subsystem processing must continue to be reduced. Reduce the transmission size On a per transaction basis, the STM flow size from / to the server is 4 to 5 times smaller than the comparable HTML page generated by the server. This feature makes it ideal for applications where access or dialing or other low bandwidth channels (eg, wireless) are still dominant.74Reduces the processing load of the server Because it relieves the burden of generating HTML on the client system and the reduced number of interactions with the server (due to the local processing capabilities of the Jview ™ subsystem, the processing load for the typical server is reduced by 30 to 50%). Improves the response time for the end user Due to the reduced size of the transmission, the use ofDynamic HTML, and the other functions and services performed locally, the Jview ™ based subsystem makes an HTML implementation based on a typical server by a factor of 8 to 10 times. Rich user interface Due to the local processing capabilities (described above), the user interface capabilities of the Jview ™ subsystem are comparable to those of many heavy client systems. Improves user interface development productivity The typical development cycle for thin client user interfaces that involves dynamic content starts with a graphics designer who creates static pages as prototypes. Once these are approved, they are provided to an engineer to code them (so that the pages can be generated in a75dynamic within the server). Often several repetitions of revision and correction follow. In general, this is a process of serial development. With the architecture of the Jview ™ subsystem, the development of the user interface can be done in parallel with the development of the server-side transaction processing code. All that is needed from the beginning is the definition of STM (that is, the data package) for each type of interaction. Once the STM is defined, both the user interface and the server-side code can be developed in parallel. In addition, there is no waste of effort in a prototype user interface. Various repetitions of the user interface can be developed and refined, and once finished, the user interface is ready for production. Only a final integration test with the server lake code is needed to ensure its operability. Provides a foundation for customizing the user interface Because the user interface remains external to the server code, and because the transaction request is based on a message, the architecture of the Jview ™ subsystem supports a high degree of customization of the user interface (without the need to modify the76code on the server). Commercial example The electronic subrogation network is an example commercial of a complete operating system representing the concepts described herein specifically for the vertical market of subrogation claim processing in the insurance industry. Terminology This section contains terminological definitions that are useful for understanding the concepts described in the description below. Client-based search engine A client system must have a search engine that supports HTML3.2 (or higher) and a simple ECMA 1.0 (or higher) program. The simple ECMA program is commonly referred to as JavaScript. The examples include, not limited to Microsoft Internet Explorer v 4.2 or higher or Netscape Navigator 4.7 or higher. Focus on server-based HTML generation Any focus on the server produces a flow ofHTML and where this flow contains the tags of the user interface so that the search engine only needs to "present" this flow of HTML to show it. End user session It is a finite period, usually denoted by77explicit system input and system exit events that allow a given user to perform one or more specific processing requests for the application. Basic thin client architecture An architecture that provides application functionality to an end user through a client that is based on a search engine to access a server, where the client based on the search engine does not depend on any special extension including, but not limited to, non-standard add-ons, transferable Java applications and / or ActiveX controls. "Site Transaction Message" (STM) A message between a browser and a server conforms to the standard HTML format. This message is used to transmit transaction data between a server and the search engine. Unlike typical HTML messages, it uses a JavaScript syntax to encapsulate the transaction data. DETAILED DESCRIPTION - Jview ™ The Jview ™ subsystem is an object-oriented system consisting of a set of graphic file modules, JavaScript and CSS. The Jview ™ subsystem runs inside search engines that support ECMAScript 1.0 (ie JavaScript). This section contains detailed descriptions of the78process and the components related to the Jview ™ subsystem and analyzes the concepts and technologies known in the field of computing for example: Design and object-oriented programming; basic Internet fundamentals (browser / server interaction, HTTP requests / responses, basic TCP / IP elements, etc.); HTML; CSS; JavaScript; Document Model W3C (DOM) Jview ™ Subsystem Files The files that make up the Jview ™ subsystem can be divided into the following categories: core, business classes, images, central display components, visualization components, domain components, forms / forms, logos and query components of the application. Central Files These files perform the generic services of the Jview ™ subsystem used by all application interactions. These files are small subsets of the general application system. Because these files are reloaded by the search engine with each interaction, it is important to minimize the total size and number of79the files in this set. The following table describes the files included in this category.
Commercial classes For each vertical application, the commercial classes represent the commercial objects that are used within said vertical application. A file is defined by the object80commercial. These definitions refer directly to the definitions of the business object (class) that are implemented on the server (as defined in the data model or application repository). Forms / Forms At each server interaction, the Jview ™ subsystem displays a "form" or "form" in the data area portion of the user interface structure of the Jview ™ general subsystem. A form is used to display a collection or a list of various commercial items (commonly in a summary format). A form is used to visualize a single commercial element (commonly in a detailed format). For example, a "form" can be used to display a list of "requests": a "form" is used to display the details of a specific request from that list. For each vertical application, one or more forms and forms are defined. The complete collection of forms and forms for a given application represents the complete set of interactions in the user interface for that application. A complex application system typically consists of hundreds of forms and forms. Central display components These files are used to define the abstract display classes from which other components81Application specific display can be subclassified. By doing so, all the application components inherit their common capabilities from the central display classes. This allows the Jview ™ subsystem to maintain a consistency of the user interface within a given application. The following table describes the files that are written in this category.
File Description / Functions jvd_Table_000.js The component of the table contains the definition of the JVDTable abstract class. This class is subclassified by other display components specific to the application to define a specific table of the application within a form or form. jvd_Pane_000.js The panel component contains the definition of the JVDPane abstract class. This class is subclassified by other display components specific to the application to define a specific panel of the application within a form. jvd_GroupBox_000.js The GroupBox component (group box) contains the definition of the JVDGroupBox abstract class. This class is subclassified by other display components specific to the application to define a specific group box of the application within a form. jvjVField_O00.js JView "". Field component. Contains the definition of the JVField class. This class is used to display a single element of business data within a form. jvj'vComplexField_00 JV¡ew "vl. The complex field component contains the O.js JVComplexField class definition.This class is used to visualize a complex array of multiple commercial data within a form. jvd_Doma¡n_000.js Component of domain selection Contains the definition of the JVDomainComponent class This class is used when multiple values of a domain are displayed to a user in one form jvjvquery_000.js The JVQuery component contains the definition of the JVQuery abstract class. subclasses using the query components (described later).82Display components For each vertical application, one or more visualization components are defined and these contain the specific data elements of the application that the user will visualize in a form or in a form. To maintain a high degree of consistency of the user interface within the general application, each display component is subclassified from one of the components of the central display. Query components A "form" is typically defined to display a list of homogeneous elements in a summary format (for example, a table). In many cases, the items in the list share one or more common characteristics, for example, a list of requests awaiting shipment, a list of clients that are "active" and a list of open accounts, etc. In many cases, users want to filter the list from a larger list to a smaller list. For each vertical application, one or more components of the query are described because they allow the user to filter the elements that are displayed in a particular form. In this way, for each form that is defined, one or more query components will be defined. A query component is used to limit operations83filter / query that can be done in a specific form. Domain components When entering data for a specific business data element, it is often required that the value entered belongs to a previously defined list of values (that is, it exists within a domain). For example, a domain for "gender" can contain the values "M" and "F". For each vertical application, one or more domain components can be defined. Each component defines the list of values that make up the domain of the specific application. Once defined, the Jview ™ subsystem can then use this list to facilitate data entry (by displaying the lists of values from which the selection can be made) and for validation. Images Files in this category represent any generic graphic file that is used through the Jview ™ subsystem and not specific to any particular vertical application or client. Logos The files in this category represent any specific application or client graphic files that are used within a given vertical application.84Jview ™ Subsystem Classes The classes that make up the Jview ™ subsystem can be divided into the following categories - STM, base and visualization. Central classes The central classes represent the classes that perform the generic functions and services that are used by the complete Jview ™ subsystem. The following table describes the classes that are included in this category.
STM Classes The STM classes are used to represent the main components of the STM that are received from the server. The following table describes the classes included in this category.85Base classes The base classes represent the hierarchy of the abstract class that is used to represent the data and the structure of the business information that is received from the server in the STM. The following table describes the classes that are included in this category.
Class Description / Functions JVBase Class of base object. This abstract class contains the attributes that are common to all other JView ™ base objects. All the other JView ™. The base classes are subclasses of this class.
JVList List class. This abstract class is used to represent a layout of other base objects (that is, an arrangement of JVBObjects or JVGAttr objects).86Display classes Represent the hierarchy of abstract classes that are used through the display components to define and control the user interface. The following table describes the classes that are included in this category.87 Class Description / Functions JVDisplay Class of display object. This abstract class contains the attributes that are common to all other JView ™ display objects. All others JView. The visualization classes are subclasses of this class. JView "". JView class "" 1. This class is used to represent the object of the form or current form for the current interaction. It works as the anchor point for the hierarchy of the display object component. JVQuery Query component class. This class is used to represent the current query component (if defined) for the current interaction. The definition of the query component specific to the application creates an instance of this class to contain the specific data elements, as well as their values used to control query / filter operations. JVDTable Class of table components. This abstract class is used to define a component of the table within the user interface (Ul). It provides common generic services for all tables. All the components of the tables specific to the application are subclassed from this class. JVDPane Class of panel components. This abstract class is used to define a panel component within the user interface (Ul). It provides common generic services for all panels. All the components of the panels specific to the application are subclassed from this class. JVDGroupBox Class of components of the group box (GroupBox). This abstract class is used to define a component of the group box within the user interface (Ul). It provides common generic services for all the tables in the group. All the components of the group tables specific to the application are subclassed from this class. JVDDomainComponent Domain component class. This class is used to represent an application domain (if defined) for the current interaction. For each interaction, various domain definitions can be used and in this case, an instance of this class is created for each domain. The application-specific domain component creates an instance of this class to contain the specific data elements, as well as their values used to control search, recovery and domain validation operations.
JVField Component Class. This class is used to define a field component within the user interface (Ul). It provides common generic services for all fields. JVComplexField Class of complex field components. This class is used to define a complex field component within the user interface (Ul). It provides common generic services for all complex fields.88Format and structure of the STM The "Siteras transaction message" (STM) is a hierarchical structure of pairs of key values that are specifically designed to contain commercial data, in raw formats, transmitted between a server and a search engine. It is similar in structure, capacity and objective to other data coding mechanisms (for example, XML, PList, etc.). This format allows the Jview ™ subsystem to achieve high performance and broad search engine capacity. The STM contains the following logical subsets of data - header, navigation bar, business objects, list of functions, messages and domains. Header This section contains data elements that are used to maintain the Jview ™ subsystem environment and coordinates the execution of a transaction between the server and the Jview ™ subsystem that runs in the search engine. Navigation bar This section contains the data structures used in the Jview ™ subsystem to build the navigation bar within the user interface. The navigation bar provides the user with a system of hierarchical menus to access the functions within the application system.89Business Objects This section contains the business objects (business data) related to the function of the application that is running. Within the STM, these commercial objects exist in their primitive object format, using these commercial objects, the Jview ™ subsystem provides a presentation that is easy to use for the user (that is, generates the HTML that is displayed in the search engine) based on in the definition of! form or form specific to the application (object of the Jview ™ subsystem contained in each interaction.
List of functions This section contains a matrix of the functions of the application that the user can perform. This list allows the system to reinforce a first level of security. Messages This section contains an array of any messages in the application that were generated as a result of the execution of the last function of the application. These messages can be information, warnings or errors. Domains This section contains a matrix of the definitions of the dynamic domains that have been sent from the server (where the content of the values within the domain are determined dynamically through the conditions of the application with each function). The definitions of90Static domains where the values within the domain do not change are provided through the domain components (ie, JavaScript files). However, these static domain definitions are not transmitted within the STM. HTML message format of the STM When receiving the HTTP response from the server, the search engine performs its normal functions related to processing in an HTML message. When initially received in the search engine, the STM is encoded within a standard HTML stream. A message shows it is contained in diagram 1. The table below summarizes the main parts of the message (the line number references refer to the sample message in diagram 1).
Line (s) Description 1-4 Standard HTML tags. These tags declare the flow as an HTML stream. The general flow of HTML is declared on lines 1-219. The HTML HEAD portion (which contains the STM) is declared on lines 3- 207. The HTML BODY portion is declared on lines 209-218.5 Inclusion of the cascading style sheet.91Includes the main JView '™ JavaScript file. This statement causes the JView Core to load. Includes the definition of JView1 M in the form or in the form. This statement provides the definition of the specific form or form that is displayed within the JView ™. Structure of the user interface. This statement also causes all the definitions of the class to be loaded. If a "form" is displayed, this line provides the definition for the specific query component of the application that will be used with the form. -206 STM The complete STM encapsulated in the JavaScript functions. -48 Header This is the portion of the STM header. -59 NavBar It is the navigation bar portion of the STM. In this example, the navigation bar contains six different navigational elements on lines 52, 53, 54, 55, 56 and 57. -143 Commercial objects This is the portion of the commercial objects of the STM. In this example, there are two instances of the business data contained in this section. Both business objects are SAFolder_Subro objects. The first instance is defined through lines 62-101, the second instance is defined through lines 102-142. 5-162 List of Functions It is the portion of the list of functions of the STM. In this example, the function list contains two different function entries on lines 147-153 and 154-160. 4-169 Messages It is the message portion of the STM. In this example, two different application messages are defined on lines 166 and 167. 1-200 Domains This is the portion of the STM domains. In this example, we define a unique application domain called "RespondingCompanies" (counterpart company) that contains 4 domain elements. 9-218 HTML BODY (HTML body) These lines represent the HTML body declaration. In most standard HTML streams, this section contains a large number of definitions that define the format of the user interface that is made through the search engine. With the JView ™ subsystem this section is virtually empty. On line 209, the "ONLOAD =" parameter causes the browser to invoke the JView ™ Manager to complete the JView ™ initialization and generate the HTML that is displayed in the search engine for this interaction.92STM JavaScript functions Within the HTML flow described above, JavaScript functions are used to encapsulate commercial data. By using these functions, any commercial data structures, simple or complex, can be defined. For an STM portion of the message, the following JavaScript functions are used: NS unique objects (< classId >, <objectId>, <instance me>) NE () These functions are used to define a node of single object. The NS () function is used to start the object declaration and the NE () function is used to end the declaration. A single object node can contain other unique objects, array nodes, or attribute nodes. When the object node is defined the < class > specifies the type of object that is represented, the < < objectid > is your unique object identifier, and the < instancename > is the name by which the main object (if any) refers to this object. RS object arrays (<instanceNam e>) RE () These functions are used to define an array node. Essentially, this type of node is used to define a collection of objects of the same type / class. The RS () function93it is used to start the declaration of the matrix and the function RE () is used to finalize the declaration. A node in the array can contain any number of unique objects (NS) or generic attribute (GA) nodes. When defining the array node, the < instancename > is the name through which the original object (if any) refers to this matrix. AttributeAB (< attributeId >, < value >) AD (< atcributeld >, < value >) AF (< attributeld >, < value >) AI < < attributeId > r < value > ) AM (< attributeld >, <value>) AS (< attributeId >, < value >)These functions are used to define a single attribute node (data element) within an object (NS). The names of different functions refer to the primitive type of data that is represented by the attribute - boolean (AB), date and time (AD), floating numerical point (AF), numerical integer (Al), memo (A) and chain (AS). When an attribute node is defined, the < Attributeld > is the name by which the original object refers to this attribute, and the < value > is the value of the attribute data. GA generic attributes (<attributeType>, <valuel>, <value2>, <valuen>) These functions are used to define a single generic attribute node (complex data element) within a matrix (RS) This attribute can only be used within a94matrix node. It is a special type of complex attribute and the interpretation of the attribute type and the values are left to the original object. Full mode format compared to raw mode In the example of the previous message, the "full mode" format is used. In this format, the identifications of the classes and the identifications of the attributes are expressed as complete character strings. A "raw mode" format is also used which further reduces the overall message size by replacing the representations of the character string of the class identifications and attribute identifications with numeric codes. Additionally, the raw mode can use the JavaScript function of the data encapsulation or the syntax of the JavaScript matrix. The JavaScript matrix method is preferred for production since it eliminates any overhead associated with the execution of the data encapsution functions itself. When using this method, all data encoding rules conform to those defined through the JavaScript syntax. The following summarizes various STM formats:95STM full modeNS ("STMHdr", nuil, "oHdr"); AB ("readOnly", 0); AD ("dateCreated", "20000531105702"); AF ("amtTota", 17.43); AI. { "count", 4), - AM (* comments "," T is is line l \ nThis is line2 \ n "), - AS (* conipanyName", "Insurance Property &Casu"); NE ();STM raw mode (using the encapsulation of the JavaScript functionNS (l, null, l), · ABILIO); AD (3, "20000531105702"); AF (, 17. 3); AI (8.4); AM (2, "This is line l \ nThis is line2 \ n") AS (7, "Insurance Property &Casu"); NEO;Raw mode of STM (using the encapsulation of the JavaScript matrix)STMHdr = [[l.null ,!], [1,1,0], [2,3, "20000531105702"], [3,4,17,43], [4,8,4], [5,2, "This is line UnThis is line2 \ n "), -], [6.7," Insurance Property &Casu "), -] 3;STM object formatThe processing of the STM message results in the creation of an STM object within the search engine environment. The structure of this object is illustrated in figure 21.96Object Hierarchies of the Jview Subsystem During the initialization of the Jview ™ subsystem environment, two hierarchies of main objects are constructed, the hierarchy of the base object and the hierarchy of the visualization object. Base object component hierarchy The base object hierarchy consists of base objects (derived from JVBase) that were created as a result of ST processing (as illustrated in diagram 1). This hierarchy is anchored within a global variable "goST" ough it can be accessed at any time through any part of the system. All business objects related to the function of the application are contained in the goSTM.oDATA subtree. This subtree is an array (RS) that can contain 0-n business object subtrees. For a form, it will contain 0-n business object subtrees. A form only contains a business object subtree. Hierarchy of the component to be displayed The hierarchy of the display object consists of display objects (derived from JVDisplay) that were created as a result of the processing of the form component / form of the Jview ™ subsystem in association with this infraction (as defined in line 7 of the exemplary message in diagram 1). This hierarchy is anchored within97Variable of the Jview ™ subsystem administrator instance "OJView" (the instance of the Jview ™ subsystem administrator object is then anchored with a global variable "goJM"). The display objects are used to contain the instance and the state data related to a user interface and some degree to reflect the DOM objects that are created from the generated HTML. This hierarchy is necessary because certain local operations (for example, reclassification of a table) are used to regenerate portions of the DOM, in this case, the visualization object contains the necessary data to regenerate DOM objects. Processing the Jview ™ subsystem The three different phases of the Jview ™ subsystem operation are described in detail in the following sections. Initialization Interaction Request presentation Initialization of the Jview ™ system With each HTTP response received from the server, the Jview ™ subsystem environment within the search engine is completely rebuilt. Because of this, the system was designed by modules to minimize the delays associated with this initialization. Some platforms98The search engine allows some data to persist between interactions (for example, Cookies, IE behavior, etc.), different from the buffering mechanisms in a normal search engine (that is, it is used for HTML pages, graphics, CSS and JavaScript files), the Jview ™ subsystem does not rely on any specific mechanism of a search engine to buffer the data between server interactions. Initialization of the search engine When receiving a new HTTP response from the server, the search engine performs any internal initialization and processes the newly received HTML stream. Load in central initialization After the search engine loads the CSS file, the JVMain JavaScript file is loaded and processed through the search engine as indicated below. First a series of global constants (necessary for initialization) is processed. The class definition for the tracking administrator is processed. The tracking manager is represented and initialized. The creation and early initialization of the tracking manager allows other parts of the JviewTM subsystem to record the tracking entries for debugging purposes. The tracking manager is anchored in the global variable goJVTraceMgr so that you can access it to99through any part of the system. The class definition for the load manager is processed. The load manager is represented and initialized by itself. The load manager is used to track all JavaScript files (for example, forms / forms, components, classes, etc.) that have been loaded. The load manager is anchored in the global variable goJVLoadMgr in this way you can access it through any part of the system. A series of JV_INCLUDE functions are processed to load the other JavaScript files that form the core of (1 WITHOUT TM) (refer to the "include" section of the Jview ™ for more detail.) As a consequence, the following central files are loaded in the sequence when the search engine completes processing for JVMain - Jview ™ Administrator Class (jv_jvmgr_000.js), Jview ™ Base Classes (jv_jvbase_000.js), Jview ™ Display Classes (jv_Jvdisp_000.js), Class of form / Jview ™ form (jv_Jview._000.js), STM classes (jv_stm_000.js), Domain administrator class (jv_dommgr_000.js) and global constants (jv_global_000.js). the load manager A series of global function definitions is then processed, these functions provide services100General features that can be used anywhere in the Jview ™ subsystem. After the processing for JVMain is complete, the search engine loads and processes each of the central files that were included in the previous paragraph. Creating the Jview ™ Subsystem Administrator During the processing of the JVIEW global file, the administrator of the Jview ™ subsystem is exemplified. This object is anchored in the global variable goJM so that it can be accessed through any part of the system. The initialization of this object is deferred (see below "initialization of the Jview ™ subsystem administrator"). Class loading the forms / forms application Once the loading of the central files of the Jview ™ subsystem is complete, the search engine continues to process the assertions in the HTML stream from the current HTTP response. The next statement in this flow would be a [SCRI PT] (simple program) label that is referenced by the JavaScript file for the specific form or form of the application. This statement causes the search engine to load and process this file as indicated below, the method definitions and additional attributes for the JVIEW class (specific to this form) are processed. These definitions provide the101JVIEW class its specific behavior for the application for the current interaction. A series of functions JV_INCLUIR is processed to load the other JavaScript files that are used through this form / form. There are two main groups of files that are included, visualization components and business classes. A form or form of the Jview ™ subsystem is constructed by assembling one or more display components (described below in "Jview ™ subsystem user interface architecture"). The "includes" visualization component causes the loading of all the visualization component definitions that are necessary for this form / form. Within the business object portion of the STM, each business object requires that its definition of application class exist within the JavaScript environment within the search engine. The business class "includes" causes the loading of all business class definitions that are necessary for the current STM. After completing the processing for the specific form / view of the application, the search engine loads and processes each of the files of the business class and visualization component that were previously included. Loading the query component Once loading the form / form of the102application, component of visualization and files of the commercial class is complete, the search engine continues with the processing of the affirmations in the HTML flow of the current HTTP response. If a form is processed for that interaction, the next statement in this flow will be a < SCRIPT > that references the JavaScript file for the query component specific to the application. This statement causes the search engine to upload and process this file. STM processing - creation and initialization of the hierarchy of the base object After all the application-specific and central files of the Jview ™ subsystem have been loaded, the search engine continues with the processing of the assertions in the HTML flow from the current response of HTTP. The following statements in the flow are in the online JavaScript statements that the STM represents. The search engine processes these statements as indicated below, the search engine executes each JavaScript STM function in the order in which they occur within the HTML flow (for example, NS (), RS (), etc.). When processing each function, a new node (object) is created in the base object hierarchy of the Jview ™ subsystem. For the NS () functions, an application-specific object is created (based on the identification of103class specified in the NS () function. For the other functions of the STM the type of object created depends on the specific function of the STM as follows: RS () - JVList (List of JV) AB () - JVBoolean (Boolean of JV) AD () - JVDate Time (JV date and time) AF () - JVFIoat (JV Float) AI () - JVInteger (JV Integer) AM () - JVMemo (JV Reminder) AS () - JVString (JV Chain) GA () -J VGAttr (JVG Attribute) When creating each node, JVBase initialization is executed. This initialization establishes the JVBase attributes that are used to represent the union of that node with the hierarchy of the base object (that is, original, secondary, brother, etc.). Based on the sequence of statements in the STM, a hierarchy of the base object is created from top to bottom and from left to right. When you create each application-specific subtree, any application-specific initializations are executed. This initialization, if one exists, exists within each business class of the application as an lnit () method. The application-specific initialization performs any data manipulation specific to the application that is needed through the current interaction. After104After executing the STM JavaScript functions, the hierarchy of the base object of the Jview ™ subsystem is created. This object hierarchy contains all the commercial data, for example commercial objects, sent from the server in response to the previous request. Initialization of the Jview ™ subsystem administratorAfter having processed the STM functions, the lnit () method of the Jview ™ subsystem administrator (JVMgr) is executed. This method is activated through the "ONLOAD =" parameter of the < BODY > in the HTML stream. The following summarizes the processing performed in this method. Initialize the domain administrator This initialization causes the processing and establishment of any domains contained in the STM (in the domain section). Create an instance of a JVIEW object. At this point, only several JVIEW class definitions have been processed (both application-specific and generic). At this time, the real JVIEW object (form or form) is created. This object anchors the display hierarchy that controls the user interface associated with the current interaction. At this time, the hierarchy of the display object is created and initialized. This complex process is105describe later. Upon completion of this process, control is returned to the Jview ™ subsystem administrator and its initialization is complete. Creation and initialization of the initialization object hierarchy This process causes the creation of visualization objects that are used to generate and control the user interface for the current interaction. It is activated when invoking the lnit () method of the JVIEW object. Within this method, the following processing is performed (for reasons of brevity, any references to "form" below implies a form or a form). Any application-specific form initialization is performed by invoking the InitViewQ method for the JVIEW object. This method allows the form to perform any specific processing of the application before generating and viewing the HTML. Said initialization includes initializing component variables that contain references to any visualization components created later, initializing other variables based on the data conditions within the base hierarchy, classifying commercial data within the base hierarchy, etc. Once the form has been initialized, the visualization components are created and the HTML is generated in a single106process. This process is activated by invoking the CreateHTMLQ method of the JVIEW object. Before invoking this method, an array is created and passed to this method as a parameter (that is, the HTML matrix). This matrix is used to contain all the HTML assertions that are generated by all the visualization methods and the components invoked during the processing of the CreateHTML () method. This method does the following: invokes the CreateHeader () method to generate the HTML for the portion of the header of the user interface; invokes the CreatelnfoBarO method to generate the HTML for the portion of the information bar of the user interface; invokes the CreateNavBarQ method to generate the HTML for the NavBar portion of the user interface; if there is an application message, call the CreateMsgArea () method to generate the portion of the message area of the user interface; for a form, call the CreateActionBarQ method to generate the HTML for the portion of the workflow bar of the user interface; and invokes the CreateDataArea () method to create / initialize any display component and generate the HTML for the data area portion of the user interface (the portion that contains the application-specific information). This method is defined in the Jview ™ subsystem file specific to the application for the current interaction. This one will do any of the107next 1) directly generate HTML, 2) create any secondary display components that form the user interface for this form, or 3) use a combination of both techniques. For each visualization component created, the following processing occurs. The visualization object for this component is exemplified and linked in the visualization hierarchy. Any initialization of the component occurs within the constructor of the class for that visualization object. The C reate P re HT M L L method is invoked for the newly created visualization object. This method provides an HTML generation oriented to the container through any superclasses for this object. The CreateHTML method is invoked for the newly created visualization object. Similar to the previous, this method causes the generation of any specific HTML for the application for this component. To do so, 1) it will generate HTML directly, 2) it will create any secondary display component that forms the user interface for this form, or 3) it will use a combination of both techniques. This process allows to lodge in an orderly manner and create isolated visualization components outside the initial JVIEW object. This process supports the construction of a simple or complex user interface. The CreatePostHTM L method will be invoked for the display object108newly created This method provides an HTML generation oriented to the container through any superclass for this object. After completing the CreateDataAreaQ method, some special HTML tags are generated. An HTML-JVFORM_STM form is created. For the forms of the Jview subsystem the transfer of files from the local environment is supported, a device is created on the standard searcher's file screen (STMFILE) is created within this HTML form (CreatePreHTML). Finally, a special hidden file (STMDATA) is adefined within this HTML form (FORM HTML (< INPUT TYPE = "hidden" ... >)), this field is used to contain the STM flow outside the limit for any subsequent request to the server. Upon completion of the main CreateHTML method for the JVIEW object, the HTML flow is prepared and the DOM object within the search engine for the body portion of the current document is updated within the new HTML (this process is further described in "HTML generation" a continuation). At this point, the "focus" of the user interface is established (based on the definition within the Jview ™ subsystem of the first field that is to receive the input focus), and control is returned to the administrator of the Jview ™ subsystem .109Initialization of the Jview subsystem administrator(continued) After you have created the user interface, the administrator of the Jview ™ subsystem will complete its initialization when performing its response time calculations. At this point, control is returned to the search engine and control of the user interface is returned to the user. Jview ™ subsystem interaction Once the control is returned to the user, the Jview ™ subsystem environment allows the user to operate locally (without server interaction). To do so, the Jview ™ subsystem relies on a dynamic HTML mechanism within the search engine to perform the services related to the interaction. These services include the following: Dynamic classification Formatting and visualization of data Expansion / compression of portions of the user interface (for example, panels) Formatting of print and preview Hierarchical menu Syntactic editing and validation Application complex validation Application calculations The HTML that was initially generated contains the definitions that allow the activation of methods110Specifics within visualization objects of the Jview ™ subsystem in response to any dynamic HTML events generated by the search engine in response to various user interactions. A key aspect of this local interaction refers to data entry. For any data entered by the user, the Jview ™ subsystem environment performs a syntactic validation (for example, it assures valid numbers, dates, etc.) and invokes any specific validation of the application defined within the business classes. Once these validations have been made in a satisfactory manner, the specific base object affected by this data (within the hierarchy of the base object) are modified with the same new data. In this way, when the user interacts with the user interface, the hierarchy of the base object is updated dynamically to reflect the current state of the data. The importance of this will be clearer later when describing the submission of requests to the server. For more information about these services, refer to the "Jview ™ subsystem services" section. Submission of requests to the Jview ™ subsystem The user will continue to operate locally within the search environment until he selects an element of the user interface and activates a new request to the server.111Within the Jview subsystem environment, all these requests are processed and generated from a central point within the Jview ™ subsystem environment, namely the administrator of the Jview ™ subsystem. The following summarizes the application submission process. For any user interface elements that trigger a request to the server, the HTML ensures that the elements cause an invocation to the InvokeFunctionO method within the administrator of the Jview ™ subsystem (JVMgr). The InvokeFunctionO method performs a parameter validation and then invokes the JVMgr method. SubmitHost equest (), to request presentation to the server by the Jview ™ administrator. The JVMgr method SubmitHostRequest () does the following: it saves the status of the current navigation bar (that is, which menu levels are open / closed) within an exemplary variable in the STM header; updates other variables in the STM header with the values of the specific data for the new request (for example, function name, string type, object identifier, transaction parameters, OLS command, qualifier, and other environment context variables of the Jview ™ subsystem); and build the outgoing STM flow for the request by crossing the hierarchy of the base object to112the subtrees of the header and business object and thus create a unique text flow (whose format is identical to the STM format in the limit shown in diagram 1). In fact, the specific format that is used depends on the server and can be any serial syntax that can represent a hierarchical structure of key pairs: value (for example STM, XML, PList, etc.). then the resulting flow is stored in the special form variable (STMDATA), which was created when the HTML was initially generated (refer to 2g in the previous section "creation and initialization of the hierarchy of the display object"). Based on the type of request (no editing or editing), the request is presented to the main server in two ways. For non-edition requests (that is, requests that do not cause data modification on the server), the form HTML HTML FORM JVFORM_STM with METHOD = GET is presented. For editing requests (that is, requests that cause modification of data in the server), the form HTML HTML FORM JVFORM_STM with METHOD = POST is presented. After presenting the request to the server, the control is returned to the search engine so that it waits for the response of a newly issued request. Jview ™ system services Within the general subsystem processing113Jview described above, specific services are performed. This section details the operation of said specific services. "Include" capability of the Jview ™ subsystem The "include" capability of the Jview ™ subsystem was created to isolate the server from the specific manner in which the module was placed in the center of the Jview ™ subsystem. This allows the server to merely specify a unique Jview ™ subsystem file (ie, jv_main_000.js) in this HTTP response stream. Within that file, other files are subsequently included to complete the loading of the central part of the Jview ™ subsystem. This approach allows the central part of the Jview ™ subsystem to be divided in one way or extend without requiring any server changes. The standard search engine environment does not provide a generic mechanism to "include" JavaScript files. In this way, the following process is used. Inside the header section < HEAD > of the HTML stream for a given HTTP response stream, a reference to an initial primary JavaScript file that uses an HTML tag <SCRIPT SRC = ... > it defines. The search engine loads the named JavaScript file through this tag from its local buffer or from the server. Once loaded, the search engine starts the114processing of the affirmations defined in this file. These statements can be JavaScript definitions or executable statements. To "include" another JavaScript file, a series of executable JavaScript statements are contained within the main JavaScript file to do the following: build a string variable that contains a new HTML tag. </ P> SCRIPT > for the JavaScript file that will be included and performs a document function. write that specifies this new string variable. This function causes the new HTML statement to be written to the current flow of HTML that is in process (in front of any HTML assertion that is sent from the server). Once the search engine completes the processing of the main JavaScript file, it then processes any newly inserted HTML assertions that were created dynamically by running the JavaScript in the main file, thereby causing additional loading of the JavaScript files. Essentially, the processing is the same as if the server had included the additional JavaScript files in its original HTML stream. Monitoring management Within the Jview ™ subsystem environment, the tracking administrator maintains the information of the115Tracking that is useful for debugging purposes. The continuation process is used to manage the tracking information. In the initialization, the tracking administration locates a matrix (with a fixed number of entries) for the tracking data. The tracking manager is anchored in a global variable goJVTrace gr. Whenever the AddTraceEntry () tracking manager method is invoked, the tracking administrator adds the new tracking entry to its internal tracking table. When the tracking table is full, the tracking manager returns to the beginning and replaces the oldest tracking entries with the most recent tracking entries. Other tracking manager methods are available to display the tracking table. Optimization of Jview ™ subsystem initialization Due to the fact that the Jview ™ subsystem environment must be completely reconstructed through the search engine, it is essential to keep the processing overhead related to initialization to a minimum. One mechanism used to reduce the type of initialization was to place the Jview ™ subsystem in modules in a variety of different files. This approach presented several advantages. Regarding the combined sizes of116In the complete application system files, the central files of the Jview ™ subsystem represent a small subset (15% or less). Once a file from the Jview ™ subsystem is transferred from the server, it is placed in the local search engine buffer, unless the file changes, any subsequent references to it will be satisfied from the local search engine buffer (instead of to recover the server). The placement in the general module of the system minimizes the number of files needed for each interaction of the application. Although the general application system can comprise hundreds of forms, forms, reports and related components, a user only needs to transfer the files needed for the current interaction. In this way, the Jview ™ subsystem avoids the delays of a long "initialization" associated with the loading of a monolithic system (for example, a Java application, various Java applications, etc). Due to extensive modularization, if a Jview ™ subsystem file changes, you only need to transfer the new Jview ™ subsystem file, and not the entire system. State and context management With each interaction with the server, the Jview ™ subsystem environment that runs inside the browser is completely regenerated (reinitialized). Because the117system is not based or uses any persistence mechanism provided by the search engine to register its status (for example, cookies, IE behaviors, etc.), the section of the STM header is used to store all the context information from the environment of the Jview ™ subsystem. When a new request is submitted to the server, the Jview ™ subsystem environment stores information related to its current "context" within the "STM" header. This information goes to the server. In response to the request, the server returns this context information, unaltered, back to the Jview ™ subsystem environment within the same STM header variable. The Jview ™ subsystem environment then uses this context information to re-establish the context it had when it submitted the original request. Security of functions To eliminate the proliferation of user-specific forms, forms and reports, the Jview ™ subsystem allows those forms to be created in a way that is not user-specific. However, because these forms can be used by multiple users, it is often necessary to contain links embedded in other functions of the application. In this case, not all users are authorized to perform all functions.118The security architecture of the functions within the Jview ™ subsystem provides a mechanism to ensure that a given user can only access the functions to which he has authorization. The operation of this mechanism is summarized below. The Function List (FunctionList) portion of the STM defines a complete set of functions for which the current operator is authorized. During the creation and initialization of a form / form of a Jview ™ subsystem, any links embedded in the functions of the application on the server are all defined using the J VI method EW.C reate E mbeded Li nk (). create this form this method is invoked for each link defined in the form / form. When using the FunctionList, the JVIEW method. CreateEmbededLink (). validates that the current user is authorized to access the function application associated with the links. If not, the link is disabled or hidden (based on the parameters passed to this method). Architecture of the subsystem user interfaceJview ™ The architecture of the user interface of the Jview ™ subsystem is based on a component model. These components are organized around the structure of the user interface of the subsystem119Jview. The structure of the Jview ™ subsystem provides a consistent application workspace for the user. Because all parts of the structure are the same components, this structure can easily be modified and extended to be compatible with a large number of application systems. The structure of the Jview ™ subsystem consists of the following main components. Header area - General area to provide "brand" information for the company using the system and the vendor. Information bar - General information area that shows information about the current task and user. Navigation bar - This area provides access to specific functions within the application in the form of a hierarchical menu system. Message area - An area to display application-specific messages. Workflow Bar - For forms, this area is used to display one or more action buttons that are used to perform common application functions that affect the workflow of the specific business document that is displayed. Command area - For forms and forms, this120area is used to display one or more links that are used to display the secondary application functions related to the specific business document that is displayed. Data Area - For forms, this area is used to display application-specific information, usually in the form of fabulators related to multiple business transactions or documents. For forms, this area is used to display the application-specific information related to a single transaction or business document. Within the data area of a form or form, one or more additional display components can be defined (for example, tables, panels, group boxes, etc.). Figure 23 contains an example of a "form" of the Jview ™ subsystem. Figure 24 contains an example of a "form" of the Jview ™ subsystem. The nature based on the UI architecture component of the Jview ™ subsystem allows a component of a given application to be defined once and then re-used between various forms and forms. Generation of HTML Due to an extensive amount of generation of121HTML made within the Jview ™ subsystem environment, the performance of this aspect of the system has a major impact on the responsiveness of the system. When the Jview ™ subsystem was developed, the HTML generation techniques that were documented within the industry were not properly executed for use in a production class system. For large HTML streams (150, KB or more), these techniques often require 30 seconds or more (in a Pentium III type processor). In this way, the Jview subsystem uses a special algorithm, existing in the present, that demonstrates the ability to generate a large flow of HTML (150 KB) in less than 500 milliseconds in a Pentium III class processor. Diagram 2 consists of a section of codes that illustrates the technique of generating HTML that is used within the Jview ™ subsystem. The table below summarizes this technique (line number references refer to the code section in diagram 2).
Lines Description 1 Statement of a standard JavaScript matrix. Each element in this matrix is used to contain a fragment of the generation of HTML codes. 2 Declaration of a standard JavaScript variable. This variable is subsequently used to contain the full flow of HTML that is generated. 4-7 Affirmations of generation of HTML codes. Each fragment of generated HTML is assigned to a new element within the HTML matrix. 9 By using the "join" method of standard JavaScript (for matrix objects), a complete HTML flow is generated, the DOM within the search engine is updated with a unique atomic operation that completely replaces the HTML for the body of the document ( using the OuterHTML property). 10 Once the full HTML flow is generated, the DOM within the search engine is updated with a single atomic operation that completely replaces the HTML of the body of the document (using the external HTML property).122Classification Due to the high bandwidth capacity of the "data" inherent in the Jview ™ subsystem architecture, it can efficiently display a large number of result rows for a given business query, from 500 to 1,000 (compared to 20 to 25 that most search engines show). Once this result set is returned to the Jview ™ subsystem environment, users typically want to rank the result rows based on various columns. Within JavaScript, a primitive classification method for array objects is provided. This method of classification is based on the existence of a "compare" function that can compare two elements within a matrix and pass a return code that indicates that one element was greater or lesser or equal to another element. Within the business object portion of the base hierarchy, a matrix is used to store a complete set of business objects for the current interaction. However, because these objects are arbitrarily complex, it is not practical to statistically encode a "compare" function. Additionally, although JavaScript provides an "eval ()" function that can be used within a generic comparison function to evaluate arbitrary business objects, this function has123an intensive performance. In this way, the use of this function to classify large sets of results is not practical. To solve this constraint and provide a robust classification capacity for both multiple column and single column classification, the following technique is used within the Jview ™ subsystem: when a form is used, a comparison function is generated dynamically by codes for each column within the form; for each generated comparison function, the "evalQ" function is invoked once to essentially compile this function in an internal JavaScript format; When the form is to be classified, the system determines the columns that are classified and then passes the compiled comparison function to the classification method for the matrix that is being classified. By using this technique, the Jview ™ subsystem classification times are commonly less than one second (with a Pentium III processor) for result sets that contain up to a thousand rows. Application validation and processing Due to the rich object oriented environment that is established within the Jview ™ subsystem environment, application validation and processing are exemplified. Whenever a data element within the hierarchy of the24If the base object is modified, the "OnUpdate ()" method is invoked for each immediate original object in the base hierarchy (up to the root object, the STM). This method allows each content object to activate validation or processing logic based on the specific portion of its tree that was updated. During this process, any data modifications made to the base hierarchy are automatically displayed to the user interface. This occurs due to the union that was established between the base and visualization hierarchies. Namely, when a base object is updated, the Jview ™ system maintains a union with all the display objects that depend on this base object. From these display objects, the correct DOM object (within the search environment) can be regenerated. Response time measurement The Jview ™ subsystem, which runs on the client's browser, also measures and tracks the response time. The mechanism used to measure and monitor the response time is summarized below. Whenever a request is made, the Jview subsystem registers a local time tag (TS1) inside the client's browser and passes this to the server (along with the request). After processing the request, the response from the server will contain the original time label (TS1).125Additionally, the server provides its own main response time (main server time) that measures the duration from the time it received the server request until the server generated the response. Upon receiving the request, the Jview ™ subsystem registers another local time tag (TS2). This time label is taken at the start of the Jview ™ subsystem initialization process so that the time closest to the reception of the response is accurately recorded. After taking the TS2 time tag, the Jview ™ subsystem continues its initialization. After almost completing the initialization (just before returning the control of the search engine to the user) a TS3 end time tag is taken and the response time statistics are calculated as follows: Total response time for the end user = TS3- TS1 Jview ™ overload time = TS3-TS2 The main server response time = main server time (provided by the user) Network time = (TS3-TS 1) -the main server time These statistics are stored within the subsystem environment (within the Jview ™ subsystem manager) and transmitted back to the server with the following126processing request. The server can then store this information within the database of the application. In this way, each new request to the server contains the response time statistics for a previous processing request. This mechanism is unique in this ability to measure the actual response time experienced by the end user in their search engine. Performance optimization The wide array of available local services eliminates the need for the client to communicate with the server, thus further reducing bandwidth, response time to the end user and server processing cycles. By downloading the previous services to the client (especially the generation of HTML), a significant reduction in the server processing cycles is achieved. The central JavaScript application components used in the Jview ™ subsystem are extremely modular. This modularity helps eliminate delays in response time in an initial interaction with the server that is associated with unmodulated systems.127Multiple channel communication Multiple windows are used in the search engine when a separate communication channel is created by the server. This allows an end user to issue multiple application processing requests that are independent and parallel to the server. The OLS maintains the status of each of these parallel communication channels in a way that preserves the integrity of each request. Within each communication channel, whether structured (STM), unstructured (files), or both types of information can be communicated in any direction. Maintenance of search engine compatibility To maintain compatibility with the broader set of search engine-based clients, the lowest possible levels of JavaScript and HTML are used. Additionally, only the basic set of thin client services provided by the client search engine is provided. The system does not use special adapters, Java applications or ActiveX controls because the use of these services reduces the overall application capacity of the system in a wide range of environments. Jview diagrams The following diagrams illustrate a number of characteristics of the Jview ™ subsystem described128previously. Diagram 1 shows a sample message code from STM (full mode). Diagram 2 shows an HTML generation code of the Jview ™ subsystem.
Express mail label number: EL434959764US Case number: 208537.0004 DIAGRAM 1 - Sample of the STM message (full mode)or I heardExpress mail label number: EL434959764US Case number: 208537.0004 51. RSCoActions ") r 52. G ^ IBACTIOM", "/ 001, Eeirand Flles / 0D6, Open Filo- / 008, Penaing Accspcance" .'SuhroPoiaarsD-.l 'endingXccaptemoBAll')53. GA ("traACTION", "/OOl.Demond Filss / 006, Open Files / DlCPending Reoponse", "SubroPoiaerED_SendinBReeponEe"); I. GAI "HBACKON", "/OOl.Demand Files / 006, Opan Files / 016, Soorc ... |," SubroFolderaD_OptmS "_rcltBa._lc" 1! 55. GA ("NBACTIOH", '50, Syatem / 10, Home ', nuU! i 56. SAI'BBACTIOH "," / 50, S atem / 20, Supporf, nulll; 57. SACNBACTION "," / 50. System / 30, LogOilc', "I.ogout")co or CJiExpress mail label number: EL434959764US Case number: 208537.0004K 8 SExpress mail label number: EL434959764US Case number: 208537.0004laña viW. sitGrns "&vt; vrExpress mail label number: EL434959764US Case number: 208537.0004 215. < / KOSCRIPT > 217. < fmv > 218. < / BODYs 219. < / HTM0 >134DIAGRAM 2 - Generation of Jview HTML1. var eKTMIi = new ArrayJ); // HTML Array 2. var sHTtíL; // HTML Stream 3. 4. aHTMLíaHTML.length] = * < B0DY > "; 5. aHTML { AHTML.length] =" < TABLE "; 6. aKüSILÍAKT L. leng h] - i <: R > 'i'ü > * i'his is some text. < TDx / TR > *' 7- ... additional HTML generation statements or method calis .... 8. 9. sHTKt, = aHTML. joínC'J // Créate the HTML Stream10. JV_B0DY.OUterHTML = SHTML;BACKGROUND - Inter-Organization Workflow Manager Automated systems that process business transactions often need to manage and track the flow of those transactions within the related business process (ie, workflow). Typically, this workflow capability is explicitly encoded within the programs and programming systems used to control the system. These systems cover a wide range of commercial applications, of different complexity, which include production transmission / scheduling, request processing, human resource management, financial accounting, sales management, etc. Commercial examples of such systems include SAP, Oracle and PeopleSoft offerings. During the 80s and 90s, these systems focused on the integration of business processes and data that135they existed within an organization (that is, within the organization). Organizations successfully implemented such systems and managed to reduce their costs, improve efficiency and compete more effectively in a global economy. With systems between organizations now, these organizations seek to integrate business processes and data that exist between commercial partner organizations (ie, between organizations). Requirements and challenges At least, workflow management within an organization must be able to: 1) maintain state information related to the current state of business transactions (status). In general, the information of the state is defined so that it is easy to understand the flow of the transaction by continuing from the insertion to its conclusion, 2) maintaining property information related to the current owner of the commercial transaction, that is, the person / group / organization that is responsible for performing the next action within the transaction (property), 3) determining the operations / functions allowed that can be performed in the commercial transaction at any given point within the workflow (navigation), and 4 ) determine the new status of a commercial transaction when it is performed136an operation / function that affects the transaction (state administration). When the management of the workflow for a complex business process is explicitly coded within an application system, the following limitations are presented: 1) it is very difficult to determine whether the conditions of the business process can be handled or not; as a result, a total testing of such workflow is difficult, time-consuming and expensive, and 2) when the underlying business process changes, modifications to the programming and programming systems are required to support the changes or additions to the related workflow. In addition to the workflow requirements within an organization, the workflow between organizations requires the following additional capabilities. 1) A common structure, specific to the business process that allows all individual organizations to communicate the status of a business transaction in a consistent manner, this refers to a state of workflow in the community or a state of workflow between organizations, 2) the ability to maintain the transaction status with respect to each individual organization involved in the transaction (ie, related to its own internal systems or137business processes); this is called workflow status specific to the organization or workflow status within an organization, 3) the ability to distinguish between various organizations involved in a transaction (ie, the parties involved in the transaction), 4 ) the ability to distinguish the role or relationship that any given organization has with respect to a specific transaction, 5) the ability to manage the functions / operations that each organization can develop based on their relationship in the commercial transaction and the current state of the transaction, and 6) the ability to provide security and privacy to each organization with respect to the data and functions. Inter-Organization Workflow Management Subsystem The workflow management subsystem between organizations (or only workflow subsystem) is designed to meet the workflow requirements between organizations and within an organization. This subsystem does not depend on a specific vertical commercial process or any application. This subsystem is unique in its ability to deal with a multi-part workflow management that expands to different organizations. The following sections describe the key features and benefits of the flow subsystem138of work. General The workflow subsystem does not manage the workflow based on instructions from explicitly encoded programs and programming systems. Instead, it uses a series of workflow tables (data structures) and a unique workflow algorithm to perform all workflow management operations. Workflow tables are essentially a set of finite state machines (FSM), which define a closed cycle system for the workflow related to a particular business process. By using this approach, the workflow defined for each business process is completed (that is, there are no holes or spaces in the workflow table). Status (Community status, workflow between organizations) For workflow among organizations, workflow subsystems include a structure that allows all participants to communicate the status of their transactions using consistent language. For each business process, a specific community structure is defined (ie, terminology, status codes, etc.). The workflow subsystem can support any number of community structures139Independent. Within the folder, the stage is used to represent the workflow status of the main community for the transaction. This is used to track the general progress of the transaction through the workflow to a conclusion. For each within the folder, the parties that can operate that are defined. For each part, a state of the s part in the community is maintained. This allows the workflow subsystem to manage and track the community status of each party in each . Status (Status of the organization, work flow within the organization) To support the work flow within the organization, a parallel structure (similar to the community structure) is established within the workflow subsystem. The only difference is that this structure is specific to a given organization. This structure is used to manage and monitor any specific activity of the organization that happens within a commercial process. For each business process, a specific structure can be defined for the specific organization (ie, terminology, status codes, etc.) by type of parties. The subsystem of the flow of140Work can support any number of specific structures of an independent organization. For each part in the folder, the organization stage is used to represent the workflow status of the main organization for the transaction. This is used to track the overall progress of the transaction through your specific workflow in the organization with a view to a conclusion. For each task within the folder, the parts that can operate in that task are defined. For each part as such, a state of the task part within the organization is maintained. This allows the workflow subsystem to manage and track the specific state of the organization of each party in each task. Ownership By keeping the action part in each task within the folder, the workflow subsystem can determine which organization is responsible for performing the business transaction both at the folder level and at the specific task level. Navigation Based on the current status information that is kept within the folder and its tasks, the workflow subsystem can determine the functions that can be performed at any time by any part.141This capability is called navigation in the workflow or just navigation. By using this navigation capability, the attached system using the workflow subsystem can present to any user the list of valid business operations that can be performed at any time (subject to the user's security profile). This eliminates the need for the operator to remember the different conditions of the workflow and helps enormously in the training of new operators. At the same time, this mechanism ensures the integrity of the commercial process by avoiding "out of process" operations. State Management Based on the current status information that is maintained within the folder and its tasks, when a new function is performed in the folder, the workflow subsystem automatically updates the status information within the folder (it is say, in the folder and any task). This capability is at the center of the workflow subsystem and allows a transition in order from one trading state to another. Upon completion of any given workflow transition, the folder is now in a new state (or the same state).142Within the workflow table it is possible to define the conditional workflow. This workflow allows the resulting workflow status to be established based on the value of any number of additional business data elements contained within the folder (that is, how it is affected by the function being performed) . The definition of these criteria can be arbitrarily complex and any number of conditional workflow rules can be defined. Commercial Example The electronic subrogation network is a commercial example of a complete operating system representing the concepts described herein specifically for the vertical market of subrogation claim processing in the insurance industry. Terminology This section contains terminological definitions that are useful in understanding the concepts described in this section. Folders Each different business transaction is represented through a folder. The folder is used to logically contain all the information related to this transaction (for example, parts, tasks, documents, contacts, alerts, attachments, events, etc.).143Parties A commercial transaction involves the interaction between two or more parties where, for transaction purposes, each party takes a specific relationship (described later). With a work flow within the organization, the parties are typically different business units (for example, division, department, etc.) within the same organization. With the work flow between organizations the parties are typically different organizations or individuals. Relationship (part type) For each specific type of business transaction (folder), one or more relationships are defined. Each relationship defines the role of a particular party that will execute with respect to the transaction. For example, in a simple application administration transaction (application folder), one party represents the "buyer" and one party represents the "provider". In this way, for each part defined in the folder, this part relationship with the transaction is called a subtype of part. Figure 22 illustrates the relationships of various parties with respect to an insurance subrogation demand transaction. Tasks A task is used to represent an independent commercial activity (related to the transaction for144this folder). Each folder must have at least one task (its main task). With complex business processes, various tasks are used within the folder to manage and track multiple parallel activities related to a particular business transaction. For example, for a request management transaction (request folder), a task is defined for the same request, and additional tasks are defined for each different shipment / invoice. Action part For each task in the folder, the party responsible for carrying out the following action related to this commercial activity is called as the action part. When the commercial transaction concludes, there will be no greater commercial activity. At this point, no action part exists in any task within the folder. Function Each operation that can be performed in the folder that affects the information or the state of the folder is called a function. Based on the folder, certain functions can only be performed through a specific part type, although others can be performed by others or all part types. In a simple order management transaction some examples of functions include: issuing a purchase order (buyer), accepting an initial request (supplier),145create a shipment / invoice (supplier), etc. Business transaction An interaction between two or more parties that cause a formal exchange or a transfer of goods, services, capital, information or other resources. Examples include an insurance claim, a purchase request, booking a flight on an airline, requesting a book, etc. Organization Two different legal entities (for example, companies or individuals) opposed to different commercial units (of arbitrary size) within a single legal entity. Workflow A defined set of business operations and / or processes, triggered by an initial commercial event (commercial transaction), which proceeds in a specific sequence or order and culminates in a conclusion or termination of the transaction. The simple workflow will follow a prescribed set of operations in sequence to the conclusion (a single route). A complex workflow can contain multiple conditional routes, only one of which will be taken based on the commercial conditions present in the transaction.146Workflow between organizations A workflow that exists between two organizations with the aim of completing / completing a business process / transaction specific to those organizations. Workflow Status A specific point within a particular business workflow for any given transaction, its entire workflow typically includes many different states. Advance workflow (stage) Within the context of a commercial transaction, most transactions move from their inception to some form of closure. There may be different routes than any given transaction through the various states of the workflow towards closure. In addition, the number of possible workflows is directly related to the number of different workflow states and possible transactions allowed in the given workflow (essentially most commercial workflows are defined as "closed cycle" processes and that any transactions that enter the system will eventually come out of the system.In the inter-organization workflow management system, the current progress of a given transaction is referred to as stages.The stage is kept in the folder for each147Commercial transaction. Finite state machine (FSM) A computational model consisting of a state set, a start state, an input alphabet and a transition function that correlates Input symbols and current states with a following state. The calculation begins in a start state with an input string. Changes to new states depending on the transition function (previous definition taken from NIST-http: / / www.nist.gov/ dads / HTML / finiteStateMachine.html) DETAILED DESCRIPTION - Administration of the workflow between organizations The administration subsystem of the Workflow between organizations (or just workflow subsystem) provides workflow management both between organizations and within an organization.This subsystem does not depend on a specific vertical business process or application and is unique in its ability to dealing with multi-part workflow management that spans different organizations This section contains the detailed process and descriptions of the components related to the workflow subsystem This analysis assumes some familiarity with the following concepts and technologies : Concepts and terminology of a state machine148finite Business-oriented transaction processing concepts in general Object oriented design and programming The workflow subsystem described in this section has been implemented within the following business transaction contexts: Insurance - subrogation claims (claims, counterclaims, presentation of arbitration, etc.) Manufacturing - processing requests (purchase requests, shipping, billing, returns, etc.) Retail sales - store administration (scheduling tasks, maintaining employees, tracking schedules, etc.) General - call log and problem management Overview The following sections summarize the key concepts used within the system. General The following general descriptions guide the development of the workflow subsystem. A folder (defined later) is a container for a related set of data elements for a particular business transaction. In the purest sense, the state of149The actual workflow of a given folder is represented by the different values that exist in all its data elements at any point of time. Unfortunately, this approach is not practical for human understanding (that is, an information overload). From a practical point of view, the workflow of a given folder can be adequately represented by a finite set of value permutations that occur between a subset of its data elements. Each of said permutations is represented through a determined workflow state. This is a form of shorthand that allows humans to understand, organize and relate the processing of any commercial transaction. Folder Within the system, each different business transaction is represented through a transaction folder. Each folder has the following key features. It is a logical container for all the information related to the transaction (for example, parts, tasks, documents, contacts, alerts, attachments, events, etc.). Inside the folder, a variable (stage) of the main workflow is maintained. This variable represents the progress of the workflow for this folder. These parties represent a different set of organizations that150They have the service to interact with this transaction. Each of such defined parts is governed by its relation to the transaction (referred to as the type of parts). This list of parties is used to restrict the information that can be displayed and the functions that can be performed (through this part, with respect to your transaction). Within the folder, one or more workflow tasks are defined. A task is used to represent an independent business activity (related to the transaction for this folder). Each folder must have at least one task (its primary task). Stage For any transaction folder, the stage represents the greatest advance (ie, its progress in the workflow) of that transaction towards its final completion or closure. In general, once a transaction has changed to a certain stage, it does not return to an earlier stage. Tasks of the parties and tasks Within a folder, the tasks are used to represent one or more commercial activities that occur in relation to the completion of the transaction. The following are the characteristics of a task: The granularity of the definition of the task (that is, the specific commercial activity to which it refers) depends on the needs of the specific commercial application. By151default, a primary task is created when the transaction folder is created. When the task is created, a certain number of parts must be assigned to the task (at least one). This assignment is used to restrict the information that can be displayed and the functions that can be performed (hereby, regarding this task). Additional parties can receive guaranteed access to the task during its lifetime. Once assigned, a part is not deleted from a task. For each part assigned to a task, a task part is created. Multiple tasks can exist within a folder at the same time. This allows the system to support parallel commercial activity within a certain business transaction. Within each part of the task, there is a specific variable for the part (state of the part) for each part defined in the task. This variable is used to track the current workflow status of that part with respect to the task. There is only one action variable (action part) for each task that identifies the part that needs to take the next action for this task. Because there may be different tasks in a folder, there may be several action variables (that is, a parallel workflow can be managed). Within each task, a last variable of activity contains a description of the last activity152that was done in the task that changed the action part. Any party can see all the workflow states of a task to which it has access. Any function can change the state of one or more specific state variables of a part in one or more tasks (as defined within the workflow table). When all the states of the parts of a task are "closed", the task "closes". In this case, a null action indicator is set (that is, a task that is closed and does not require action). When the state of the main task is "closed", the stage of the folder is "closed". However, in this case, other tasks within the folder may not be closed. This allows a workflow to occur "after closure" in an orderly manner. At the point where all the tasks within the folder are "closed", the folder "closes". The actual workflow status of a folder is really the sum of all the states of all the tasks. Workflow of the community With the work flow between organizations, a common language or structure must be established for all the organizations involved in the transactions. This allows for an effective and consistent communication related to the workflow status of a given transaction. Within the workflow subsystem, the153The following data elements represent this common structure: Folder - stage Part - part type Task - part of action, last activity Part tasks - part state These data elements represent the work flow information in the community that is available for all the parts defined in the specific folder. Workflow within the organization Because any workflow within the organization must also exist within the context of the workflow within the organization (that is, the work flow that is specific to a given organization), the Workflow subsystem supports the maintenance of workflow states specific to the organization. The following data elements are used to maintain the specific workflow status of the organization: Part - stage of organization Part tasks - organization status These data elements represent the work flow information specific to the organization . This information is private for each part within the folder.154Workflow data model Figure 25 illustrates the entities of the main data and their relationships that are used by the workflow subsystem. The folder entities (SAFolder), parts (SAParty), task (SATask), and part of the task (SATaskParty) contain the actual workflow status information for a given business transaction. The workflow table contains the workflow definitions that are used by the workflow processes. Workflow table The workflow table is located in the center of the workflow subsystem. Essentially, this table is used to define and organize multiple finite state machines (FSM). These FSMs work in combination to define and control the workflow for the entire application system. This table and the related workflow processes are described in detail below. For a given application system, you define a single workflow table that contains community workflow definitions for all business transactions processed by this application. Another table is also defined that contains the definitions of the workflow specific to the organization. This table of155Workflow specific to the organization is similar in structure to the community workflow table. Workflow state transitions The main purpose of the workflow table is to allow the system to determine the workflow status below for a transaction folder based on its current state and the termination of an application function determined that modifies this folder (ie, the transition of the workflow state). Within the workflow subsystem, the workflow transition mechanism is used to modify one or all of the following: stage, part state, action part, or task parts. Workflow navigation In addition to defining transitions of workflow states, the workflow table also implicitly defines workflow navigation. For any given transition folder in a particular state, the workflow table defines the functions of the application that are allowed to perform in this state. Based on these definitions, the workflow subsystem can return this list of valid functions and applications to any folder at any time. With an online system, this is useful since it allows the system to guide or navigate a user through the156system showing the allowed functions that are valid. This reduces the knowledge of the workflow required by the users, a speed of training and allows less trained users to operate the system. Managing the action part A problem that exists with the work flow between organizations is to determine, at any time, which organization is responsible for performing the next action in the transaction. With each task, the actionParty field in the action part contains the type of part of the party that is responsible for following the next action in this task. In fact, because multiple tasks can exist within a folder, the workflow subsystem can track the action part for several tasks. Structure of the workflow table The workflow table contains records that define the workflow for all business transactions within a particular application system. The attributes detailed within this table are contained in diagram 3 below. The records in the workflow table are organized into groups along with the following dimensions: folder type, task type, stage, task part type, and part state. These groupings essentially divide the table into157several sets of workflow record together with a certain dimension. Within these dimensions, each workflow record defines the state transition of the workflow that occurs after completing the processing of a specific application function. Additionally, each workflow record implicitly defines the application's functions that are "valid" from a workflow point of view within any given workflow state (thus allowing the system to support navigation in the workflow). Workflow operation code A particular workflow record can be defined to control workflow navigation, workflow state transitions, or both. The operationCode field of the operation code is used to specify which of these operations in the workflow will be performed. Conditional workflow In most cases, the transitions in the workflow states are simple and determinant, the next workflow status is determined simply through the current workflow status and the application function that It is complete. However, in some cases, the transition can only be determined by inspecting others158data elements within the transaction folder. In this case, the workflow is conditional. To support the conditional workflow, the workflow table allows multiple workflow records to be defined for the same state of the workflow and the same function of the application. These records are then differentiated through the postConditionQualifier which is a later condition qualifier. Similar to the "WHERE" clause within an SQL assertion, this field defines the condition of data under which the states are transitioned. If this condition gives a result in the evaluation of "true" the workflow engine makes the transition of states as defined in this record. If not, continue with the evaluation of the conditional qualifiers in the other workflow records (if all conditions return a "FALSE" result, the workflow engine returns an error in the workflow to the subsystem that makes the call). This conditional workflow capability also applies to workflow navigation. In some cases, a given application may or may not be allowed within a certain workflow state based on the values of other data elements within the transaction folder. To support this capability, you can define a preConditionQualifier that is a qualifier of159preconditions for each workflow record. When navigating the workflow, the system only returns functions of the application for a given workflow state where this field is null or where the qualifier evaluates to "true". Assigning additional task parts to a task As part of the transition mechanism of the workflow state, additional task parts can be added to a specific task in response to an application function. This is controlled by the taskPartyArray field, where the matrix of the part of the task is defined. Once a particular workflow record is selected for the transition of the states in the workflow, if the matrix of the tasks part contains a part type for a part that does not exist in that task, then it is added a new part type to the currentPartyArray field for that task. Managing the action part As part of the transition mechanisms of the workflow state, the action part for a given task can be modified in response to an application function. This is controlled through the nextActionParty field. Once a particular workflow record is selected for a transition in the workflow state and if the nextActionParty field contains a160Part type, then the action part for this task is updated. Additionally, if the nextActionParty field contains a "?", Then that indicates that the type of the next action part depends on the application, and in this case, the type of the next action part is provided from the subsystem invoking the workflow administrator. Workflow processing There are two different types of workflow processing that are done through the workflow subsystem, workflow navigation and state transitions in the workflow. The following sections describe this processing in detail. Navigation in the workflow The following describes the operation of the navigation mechanism in the workflow. The subsystem making the call will invoke the class method GetWorkFlowFunctions () of the WorkFlowManager class. In doing so, the following parameters will be based: OFolder-refers to the folder to which you have access; SPartyType-the type of parts of the organization that accesses the folder; AFunctions-is an empty array (which is to contain valid workflow functions).161With the GetWorkFlowFunctions () method, the following is done: based on the folder reference, the current workflow status is determined (for example, stage, task, states of the task part, etc.). Retrieve the task records for this folder. FOR EACH task within the folder (oTask), Retrieve the records of the task part for that task. FOR EACH record of the task part (oTaskParty), the query of the workflow table will be consulted using the following: SELECT * FROM * SAWORKFLOW WHERE ((FolderType = oFolder.folderType) AND (ThreadType = oTask.taskType) Y (Stage = oFolder.stage) Y (PartyTartertype = oTaskParty. PartyType) Y (StateParts = oTaskParty.partyState) Y (PartAction = sPartyType) AND ((OperationCode = '?') Or (operationCode = "B '))); FOR EACH record of the workflow returned, IF the PreviousCondition qualifier has a value of "null" THEN The function of the application specified in this record for aFunctions is added.162OTHERWISEIF the Previous Condition Qualifier gives a result of TRUE THEN The function of the application specified in this record for aFunctions is added. IT ENDES IF IT ENDES IFENFORCES FOR (no more workflow records) ENFORCES FOR (no more records of part tasks) ENCLOSES FOR (no more task records) At this time, the aFunctions matrix contains the list of application functions that are allowed for the current folder in its current state. The GetWorkFlowFunctionsO method is returned to the caller. Transitions in the states of the workflow The operation of the transition mechanisms of the workflow states is described below.
The subsystem that makes the call invokes the EvaluateWorkflowO class method of the WorkFlowManager ciase. When doing so, the following parameters pass: oFolder-refers to the folder that is being processed; oFunction-refers to the function of the application (whose processing has just been completed); sPartyType-the type of part of the organization that163access the folder; and sNextActionPartyType, if the nextActionParty field for this application function depends on the application, then this field contains the type of the next action part, otherwise it will be null. Within the EvaluateWorkflowQ method, the following was done: based on the folder reference, the current workflow status is determined (for example, stage, tasks, states of the task part, etc.) - The current stage is save in sCurrentStage. If the function of the application (oFunction) indicates that a new task must be created, THEN create the new task for this folder END IF The records of the tasks for this folder are retrieved. FOR EACH task inside the folder (oTask),Retrieves the records of the tasks of the parties for this task. FOR EACH task record of the parties (oTaskParty), the query of the workflow table is queried using the following: SELECT * FROM SAWORKFLOW WHERE164((FolderType = oFolder.folderType) Y (ThreadType = oTask.taskType) Y (Stage = sCurrentStage) Y (PartTapeType = oTaskParty .partyType) Y (PartTabe = oTaskParty .partyState) Y (Part ofAction = sPartyType) AND ((OperationOption = ' S ') or (OpcodeOperation =' B '))); FOR EACH return workflow record, IF the value for the PostCondition qualifier is "null" THEN The state transition indicated in this workflow record is performed (see below). OTHERWISEIF the result of the later ConditionCalif is TRUE THEN The state transition indicated in this flow record is made.165work (see below). ENDS IF YOU FINISH IF YOU FINISH FOR (there are no more workflow records) COMPLETE FOR (there are no more records for tasks of the parties) IT FINISHES FOR (there are no more task records) When a state transition will be made, the following operations they are produced using the values of the selected workflow record. IF the nextStage value is not "null" THEN The folder is set oFolder.stage = nextStage ENDES IFIF the value of nextPartyState is not "null" THEN It is set oTaskParty.partyState = nextPartyState ENDES IFIF the value of nextActionParty is not "null" THENSI nextActionParty = "?" THEN Set oTask.action Party =166sNextAction PartyType OTHERWISE Set oTask.actionParty = nextActionParty ENDES YESIT ENDESIF the value of taskPartyArray is not "null" THEN New parts are added to oTask.currentPartyArray. FOR EACH new part added A new TaskParty record is created for this task This new TaskParty record is added to the task matrix of the parts that are under processing(so that the state of the part for this new record of the part's tasks is initialized correctly). TERMINATES TO TERMINATE IF At this point, the transition of the workflow status is completed and the EvaluateWorkflowO method returns to the caller.167NOTE: Within this processing, the workflow evaluation is performed after the processing of the application function that modified the folder. This is necessary to allow the application to modify the data elements of the application within the folder. Once this is complete, the postConditionQualifier (and the resulting workflow) will be evaluated in comparison to the new data in the application. Example of workflow subsystem processing This section illustrates an example of the workflow subsystem within the context of the Insurance Subrogation application. Overview of the subrogation workflow A claim of a subrogation is a commercial transaction between two insurance companies, a plaintiff company and a counterparty. This claim is presented when an accident occurs between two insured vehicles, one insured by the claimant and the other insured by the counterparty (where the counterpart driver was responsible for the accident). In this case, the company making the claim has the right to seek reimbursement from the counterpart for the cost incurred in repairing the vehicle of its168insured. The plaintiff company initiates the transaction by sending a subrogation claim to the counterpart company. The application provides an ASP based on the application (electronic network), which allows insurers to process and establish their subrogation claims using an automated system. This system can interface with an insurer either electronically or manually (through an interface based on an electronic network). The workflow related to the processing of a subrogation claim is complex since the transaction can follow different routes during its life. In this way, the additional parties (beyond the claimant and the respondent) may be involved in the transaction. Figure 22 illustrates a complete set of parties that can participate in a particular subrogation transaction. Folders The subrogation application deals with the following transaction folders: Demand folder (SAFolder_Subro) Demand file transfer folder (SAFolder_DemandUpload) Company folder (SAFolder_Company)169Location folder (SAFolder_Location) Group folder (SAFolder_Group) Operator folder (SAFolder_Operator) System folder (SAFolder_System) System alert folder (SAFolder_SystemAlert)Each of the previous folders has its own workflow defined within the workflow table.
For this example, we will only describe the workflow related to the demand folder. Parties The claim folder can have the following parts: Plaintiff (D) - the main party (ie the insurer) that initiates the transaction. Responder (R) -the counterpart (that is, the insurer or the uninsured driver) responsible for the claim. Arbitrator (A), for the demands in arbitration, the organization of the arbitration. Collection agency (C), if the counterpart is an uninsured driver, the collection agency that manages the recovery. Plaintiff's Lawyer (X) - for lawsuits in litigation, is the plaintiff's attorney. Respondent lawyer (Y) -for lawsuits in litigation,170He is the lawyer of the counterpart. Insured plaintiff (E) -the plaintiff's policy holder. Secured responder (S) -the counterparty's policyholder. Tasks of the demand folder The demand folder can have the following tasks: Demand - the main task that represents the claim of subrogation. Arbitration - a secondary task that is used to monitor the arbitration activity. Litigation - a secondary task that is used to track litigation activity. Stages of the demand folder The following stages are defined for the demand folder: Init-The initial stage that is used when the demand folder is initially created. Preparation - the demand that has been created, but has not been issued to a counterparty. Issued - Demand issued to a counterpart company. Negotiation - The demand that is in negotiation between the plaintiff and the counterparty.171Arbitration - Complainant who has decided to seek arbitration. Final arbitration - the arbitration is complete and a judgment has been made. Litigation - The plaintiff has decided to continue litigation. Final litigation - litigation is complete and a judgment has been made. Closed - the demand transaction has already been closed. States of the part For each of the tasks mentioned, and for each part, specific states of the part are defined. Within the subrogation workflow, there are currently 60 valid combinations of states and stages of the part. Application functions Within the subrogation application, there are currently 60 different editing functions that can be performed in the demand folder. Example of the workflow table Within diagram 4 (shown below) there are some representative rows of the workflow table used within the insurance subrogation application. These rows show all refer to the demand folder and illustrate the workflow of a claimant (party type D) or responder (party type R).172Based on the number of workflow states (60) and application functions (60), the demand folder has 3,600 possible workflow conditions. However, because the workflow table only contains workflow conditions (valid), the final table only contains 1,000 rows (that is, 2,600 combinations are not valid). The following describes how these rows of the workflow are used to control the workflow related to subrogation. Creating a new subrogation request folder (row 344) This row in the workflow is used to control the workflow when you initially create a new subrogation transaction folder (from the function of the DemandD_CreateElectronic application).173Navigation control in the workflow for the arbitration function (row 105) This row of the workflow is only used to control the navigation in the workflow for the claimant. By using a "preConditionQualifier", this row allows the claimant to perform the function of the Demand D_Arbitrate application only if the counterpart belongs to the arbitration organization.174Establishing the action part with the help of the application function (row 808) This row of the workflow is used to control the workflow for an inquiry function that is executed through the claimant within the "negotiation" stage and the state of the applicant "counteroffer approved". Because an inquiry can be sent to one of many parties, this row illustrates the use of the "?" to set the part of the next action for this task in the folder.175Transition processing for states in the workflow only for the approval of a counteroffer (row 856) This row of workflow is only used to control the transition of states in the workflow when a claimant approves a counteroffer . Because the ability to perform this function is based on the state of176the part of the counterpart, the navigation in the workflow for this function is defined within the section of the tasks part of the counterpart (described later in the row936).from the part of another party (row 936) This row of the workflow is used to control the navigation in the workflow to ensure that a claimant can only approve a counteroffer based on the state of the counterpart party. Additionally,177when the claimant performs this function, this row is also used to update the status of the party for the counterparty.
Adding parts to a new task (row 51) When the claimant performs the DemandD_Arbitrate function (which indicates that they seek arbitration for this claim), the workflow subsystem creates a new task for this folder, the arbitration task ( as indicated in the function register for this function of178application). The workflow table contains different rows to manage the status of the workflow defined by each task within the folder. This row of the workflow is only used to control the transition of workflow states for the newly created arbitration task.
Diagrams - inter-organizational workflow management The following diagrams illustrate a number of characteristics of the flow management subsystem.179interorganization work described above. Diagram 3 - Schematic model of workflow data - Workflow table (SAWorkflow) Diagram 4 - Example of workflow table - insurance subtraction| \ 3 N > in or in or inExpress mail label number: EL434959764US Case number: 208537.0004 DIAGRAM 3 - Workflow data model schema - Workflow table (SAWorkflow) This data model schema represents the entity that is used to control the flow of data. community work that is defined for any given application. Whenever an "edit" function is performed in a folder, the workflow management methods use this table to control the stage, the state and the action part and their fields, stage, state and actionParty within the SATask and SATaskParty entities within the folder. This table is used for two objectives in the workflow: 1) Determine the next steps in the workflow allowed, based on a certain workflow condition (stage, type of part, state, substate, etc.) . 2) Determine the next status of the workflow of the folder after performing a certain function, based on the current workflow status of the folder. The workflow records within this table are organized in the following hierarchy / groups: Type of folder Type of task Stage Type of the part of the task State of the partro ro n n tn Oi Express mail label number: EL434959764US Case number: 208537.0004Attributes Name Type of Length Digits Null Required Description of decimal dataactionPartyType String 1 N R The type of part of the part that performs the functionfolderType String 64 N R The type of folder. This field contains the name of the entity in the folder to which this workflow record applies (for example, SASubfolder, SADemandUploadFolder, etc. intrinsicFunctionld String 255 NR The identifier of the intrinsic function (as specified in SAIntrinsicFunction) associated with the function that is being performed nextActionParty String 1 and 0 Specifies the type of party responsible for developing the next action for this task, if specified, this field may contain a valid part type code (for example, D, R or A), or a "?" Sign. The value "?" Is a special value that indicates that the workflow manager of the next action part is determined dynamically through the function of the application that is running. In doing so, the TPL must provide an API invocation that allows the application function to set the "nextActionParty" for a given task (during the valid call). Because several tasks may exist, it is possible that the application function must specify the action part for each task (if each task specifies a "?"). When the TPL invokes the workflow manager to evaluate the workflow for a folder, it must pass the values for the action part that were established through the application function for each task.r? 3 in or in in Express mail label number: EL434959764US Case number: 208537.0004Name Type of Length Null Digits Required Description decimal data nextPartyState String 64 Y 0 The following part specifies the state (within the specific SATaskParty entity) for this entry in the workflow. If this field is null, the specific state of the current part will be this Dart} It is not affected. nextStage String 64 AND O The next stage that is set (within the Folder entity) for this workflow entry. If this field is null, the current stage is not affected. nextStateEventPathToR String 255 AND 0 If a next state event is generated (as indicated by oot through nextStateTemplateld), this field is used to specify the key path to the root target for this event. The root goal for this key path will be the folder whose workflow status is currently being processed. NOTE: If the root object for the event is the same as the root object for this workflow entry (that is, the folder, then this field is null). NextStateEventTemplate String 255 AND 0 If an event of the next state is generated, this field is used to specify the identifier of the event template for that event. operationCode String 1 N R The workflow operation for this row is as follows: S-state change - indicates that this row is only used to evaluate the next state of the folder after performing an edit function. N-navigation - indicates that this row is only used to determine the valid set of editing functions that are allowed based on the current state of the folder. B-both - indicates that this row is used for state change and navigation operations.
I heard? nExpress mail label number: EL434959764US Case number: 208537.0004Name Type of Length Null Digits Required Description decimal data partyState String 64. NR Workflow status (specific to postConditionQualifier type String 4000 YO This qualifier is used to support workflow (conditional) .In this case, two or more rows within the table for the current workflow state specify this qualifier The system evaluates the qualifier for each row and sets the next workflow status based on the row whose qualifier evaluates to "true". : when using this field, the qualifiers specified for a given set of rows must be MUTUALLY EXCLUSIVE, in which only one and only one qualifier must evaluate to true at any given time. If this field is null, then it is assumed that the next workflow status specified for this workflow entry can be done unconditionally. preConditionQualifier String 4000 AND O A qualifier used to determine conditionally whether the function specified for this workflow entry can be performed or not. If this field is null, then it is assumed that the function specified for this workflow entry can be done unconditionally. If this field is not null, then the system evaluates the qualifier. If the qualifier gives an evaluation of "true", then the function specified for this workflow entry is allowed, otherwise it is discarded.
Neither N3 in or inExpress mail label number: EL434959764US Case number: 208537.0004Name Type of Length Null Digits Required Description decimal data Stage String 64 N R Stage of the workflow. status String 255 AND OR This field is used to set the state of the task for the specific part (SATaskParty). The workflow administrator sets the state of the appropriate part based on the value of this field as follows: Null-the state of the action part is used as the state. Not null-the value of this field is used as the state. Not null and the first character "&", the value of this field is appended to the current state and the "&" is replaced with a stkeyNextStateEventTe String 4000 AND O Relationship field (see mplate relations section below) taskPartyArray String 16 AND O Specifies the types of party that should have access to the task represented by this workflow entry. The syntax of this field is a series of strings of one or more part type codes where each of a different part type is represented by a single character (that is, the part type code). The following should be noted: this field is additive since it only specifies the parts that can be added to a task. If a specified part within this field already has access to this task, then no action is taken. If a part of the type specified in this field does not exist in the folder, then no action is taken. If a party receives access to this task, the system creates a SATaskParty to link the part to the task. For subrogation, the following part type codes are defined: D, R and A.> I heard O I heardExpress mail label number: EL434959764US Case number: 208537.0004Name Type of Length Null Digits Required Description decimal data taskPartyType String 1 N R The type of part of the part whose state variable (contained in SATaskParty) is affected. taskType String 32 N R The type of task. The types of tasks valid for subrogation are: Demand Arbitration Litigation workflowBarRootClass String 64 Y 0 Used to control navigation if this field is specified and indicates that a button (for this function) should be displayed in the workflow bar (action bar) for any shape whose root object corresponds to the class specified in this workflow entry.
M Ü1 O üiExpress mail label number: EL434959764US Case number: 208537.0004Relationships Name Type of relationship fields Required Description relationship (origin / destination)toNextStateEventTemplate 1-1 SAEventTemplate 0 If specified, SAEventTemplate, this is used to create a specific "event" for the application that represents the status change that is taking place. This case is typically used to create an event that activates a function in the background. For unconditional workflow entries, this can typically be done using "a term event" that is defined in SAIntrinsicFunction. For the conditional workflow (where a background merger needs to be activated conditionally, this relationship must be specified). NOTE: The workflow manager always creates a "generic" event that records the workflow status of the folder before and after the workflow is evaluated. This event is a "detailed" event and can be used to debug workflow problems (not to activate background functions).187Diagram 4 - Example of a workflow table - Insurance subrogation Below is a small subset of rows from a workflow table used within the Siteras Insurance Subrogation application. KovNU-ifibar - 34i 1. SiL oIder-_Subrc 2. TaskType: Desajid 3. Stage: Init 4. TaskPartyType: Definish (D) 5. Pa tyState; IniC 6. ActionFarty; D 7. Functionx Dea * .andD_Cre3teElectronic 8. OperationCode: B 9. PreConcitionQuali fier: 10. PostConditionQuaiifier: Give yourself 11. Nextstage: Preparation 12. NextPartyState: Fending Issuance 13. MextActionParty: D 14. TaskPartyArray; D HowNumbor - SOS 1. .FOiderType: SAFolder_Subro 2. TasJc ype: Demand 3. Stage: Hegotiation 4. TaskParfcy yp: CamanderíD) PartyState: Counter OffGr Approved e. ActionParty: D 7. Functinn: D_s-índD_Arbitrate 8. OperationCode: N S. PreConditionQuali fier: RGsporidarlsArbitrationMenber 10. PostCojidi tionQualiíier: 11. NexcStage: 12. NextPartyState: 13. N'ex ActionFarCyj 14. TaskPartyA-rray: -saba - SOS 1. Folder ^ ype = SAFolder "Subro 2. T s¾T pe; Demaná 3. Stage: Wegotiaticn 4. TaskPartyType: Deroander (D) s. PartyState: Counter Ofíer Approved 6. ActionParty; D 7. Functicn: Dena.noD_Inquiry 8. OperationCode: B 9. PreConcitionQualify: 10. FostConditionüualifier: 11. Kextstage: 12. NexfcPartySfcate: 13. KextActionParty: 7 14. TaskPartyArra: 1. FolderType: SAFoláer_Subro 2. TaskTyps: Dems-id 3. Stage: Negotiation 4. TaskPartyType: DenanderíD) 5. PartyState: Demond Issced 6. ftctionParty; D 7. Ptuactior ,: Deir.andD_Approve 8. OperationCode: S S. PreConditiosQualifier: 10. Postconáitionoualifier: 11. tíextstage: 12. NextPartyState: Counter Otíer? .pproved 13. NextActionParty: R18814. TaskPartyArx-ay: HowiíiBbsr - 936 1. FolderType: SAFolder_5ubro 2- TaskType: Deroand 3- Stage: Negotiation ¾. TaskParfcyType: Reply tR) 5- PartyState: Counter Offer Issued e. ActionParty: D 7. Function: Demanc-0_Approve 8. GperationCode: B s. FreConditionQualifier: 10- PostConditionQualifier: 11. NextStage: 12. NextPartyState.- Pending Response 13. Nex ActionParty: R 14- TasIcPartyArray: SteMNutnber - 51 1. FolderType: SAFolder_Subro 2. TaskType: Arbitration 3. Stage: Jssued 4. TaskPartyType: Demander (D) 5. PartyState: Xr.it 6. ActionPsxty:? 7. Function: Dewand3_Arbitrate S. OparationCode: S g. PreConditionQualifie: 10. PostConditionQualifier: U. SextSCage: ArbiUra on 12. NextParfcyState: Freparing For Arbitration 13. NextActionParty: D 1-3. TaskPa yArray: DRBACKGROUND - Transaction Processing Between Organizations During the 1980s and 1990s, many commercial transaction processing systems focused on business integration processes and data that existed within an organization (that is, within the organization). These systems cover a wide range of commercial applications of different complexity, including production programming / transmission, the application process, human resources administration,189financial accounting, sales management, etc. Commercial examples of such systems include SAP, Oracle and PeopleSoft offerings. The organizations that successfully implemented these systems achieved lower costs, greater efficiency and presented a better competitiveness. Now with the systems within the organization, these organizations seek to integrate business processes and data that exist between commercial partner organizations (ie, between organizations). Between 1999 and 2000, various exchanges between businesses ("B2B exchange") arose. These virtual markets demonstrated the enormous value of integrating business processes and data between different organizations. Unfortunately, this movement in technology failed due to a fundamental flaw in the concept of exchange, namely, that while these exchanges were good bought (due to good reduced prices to buy goods), the same exchanges were not good for suppliers. , since there was a pressure on the fall in prices due to increasing competition. The resulting market had many buyers, but not suppliers. In this way, the market collapses. Although this initial movement between stores failed, it clearly demonstrated that substantial cost reduction and greater efficiency can be achieved with systems that190automate the processing of transactions between business partners (that is, transaction processes between organizations). Requirements and challenges This section provides a general description of the requirements of an inter-organizational transaction processing system. Central processing network Unlike the processing of transactions between organizations (where the transaction processing system can be implemented directly within a given organization), the processing of transactions between organizations requires that the information flow through a central or a centralized network (either explicitly or logically). For a given vertical market, this core network is best implemented through a single neutral third party organization (ie, a clearing house). This facilitates broad participation within a given vertical network by eliminating any issues related to privacy / ownership of the data that might arise if the network were to be executed by one of the dominant organizations in the vertical market. In addition, connecting to a trading community through a centralized network greatly reduces the191number of connections needed when comparing in a point-to-point network. With a centralized network, each member maintains only a single network connection (instead of maintaining a connection per business partner). Isolation of member organizations The value of the core network lies in its ability to isolate member organizations from the implementation details needed to connect to the network. Instead of creating a single common set of standards that all member organizations must adhere to, the core network facilitates membership by allowing each member organization to communicate and integrate with the network in a way that best suits their needs and capabilities for that organization. To do so, the network must isolate all member organizations along with the following dimensions. Connectivity isolation The network must support a wide variety of interface capabilities. This allows member organizations to have diverse technical capabilities to interact with the network. Some organizations will want to interface with the network using fully automated interfaces (by communicating information from message-based transactions), while other less complicated organizations will want to192interact manually (using an interface based on the computer network). This facilitates broad participation in the network and provides isolation from the technical interface. Isolation of content and data format When building a connectivity isolation described above, the network must support a wide variety of data formats while maintaining the meaning and content of the application data within the specific vertical market. This allows members to send / receive data elements associated with each business transaction in a format that appears on their local system. To support this requirement, the network needs to perform semantic and format translations. This reduces the integration requirements as well as increasing the member's participation. At the center of this capability is the definition of a "unified data model" that is specific to the vertical market. This data model provides a single objective database where all translations are performed. In a simpler way, the incoming data is transformed from its specific member format to the prescribed format through the unified data model, the same process is done in reverse for an output information.193Business Process Isolation The above requirements allow members 1) connect and 2) exchange data in a consistent manner. Taking this capacity into account, the network should provide a common structure for inter-organizational transactions (a workflow between organizations) but also isolate each member from specific business processes and workflows that are unique to their organizations (flow of information). work within the organization). This common transaction structure is specified in a specific vertical market and defines a common commercial process that allows all members to communicate in a consistent manner about transactions in process in the network. For more information about this capability, refer to the related section "inter-organizational workflow management." In addition, this isolation also ensures consistent processing in each transaction. Instead of just passing information from one member to another, the network must provide specific processing for the required application through a specific vertical market. At the very least, this processing must keep all data related to the transaction between organizations as defined within the unified data model for194said market. Structured and unstructured information Most automated business systems deal with structured information where the structure of information is broken down into elements of related data sets (attributes) that are grouped into data entities. At the time, the data entities are stored within a database administration system. Although structured information is necessary, many transactions between organizations involve related information (supporting documents) that exists in an unstructured format (eg, images, photographs, audio, video, etc.). Because most transactions between organizations currently occur manually through mail and fax, this related information usually goes along with any structured information. The network must be able to provide storage and retrieval for structured information and for unstructured information. And, with respect to unstructured information, it must provide a means to allow all member organizations to access unstructured information without substantially increasing the technology required to perform such access (ie,195without the need for proprietary access mechanisms for specific types of unstructured information). Multi-party transactions and workflow Although most transactions between businesses involve a principal party and a counterparty (for example, buyer / supplier, manufacturer / customer, plaintiff / defendant, etc.), the workflow of the Real life consists of a complex conditional workflow that involves several parties. Unlike a transaction processing system within the organization, this multi-party access requirement refers to all aspects of the processing capabilities of transactions in the network and must be supported. Each of the following transaction processing subsystems must count for a multi-party access to some degree: processing and evaluation of business rules; security organization structure (locations); workflow management; access to non-members in the routing of a transaction; access to the common operator; closing and reservation of transaction tracking (within and between members); preparation of reports; document management and external notifications.196Data privacy and security Finally, because the network stores information about each of the members' transactions, it must provide complete security to ensure that a given organization can only access the transactions and data elements related to the transaction. that you have permission to access. Transaction processing system between organizations The transaction processing system between organizations consists of an application structure designed to cover the processing requirements of a transaction between organizations (mentioned above). This structure does not depend on a specific vertical commercial process or any application and has a unique ability to deal with multi-part transactions that expand in different organizations. This structure operates within an architecture of a general system that consists of a number of servers that work in an integrated manner. This is illustrated in Figure 26, system architecture. The system of programs and programming systems that represents this structure of the application is located inside the server of the application. This system consists of four main areas-subsystems of197interface, transaction processing level (TPL), system services and application logic. This structure is illustrated in Figure 27, architecture of an application structure. Each of these areas is described in more detail below. Interface Subsystems Transaction requests can originate from different sources, for example, manually through a network-based interface, electronically through a message-based interface, internally as a result of native processing, etc. The objective of the interface subsystem is to support the unique interface requirements of any given source of transaction origin. Because the forms of the origin of the transaction are new / unique and evolve (for example, wireless networks), the system can quickly support new transactions through the creation of new interface subsystems. The final result of each subsystem is the same, namely to convert the request of the transaction into an internal object format (an object graphic) and invoke the TPL services to process the transaction request. This centralized transaction processing structure provides the following main benefits; all transaction requests flow through a single common point within the198system, security validation is performed for all transaction requests at a single point (ie, there is no way to execute a transaction within the system that prevents the validation of security). All transaction processing is done consistently. A set of common transaction processing services are performed through the TPL (thus eliminating the need for them to be explicitly encoded within an application logic in each transaction). The following sections describe the interface subsystems that are provided to support the common methods of the origin of the transaction. Online Subsystem (OLS) The online subsystem is used to support transactions that originate manually through an interface based on computer networks, oriented towards HTML. This subsystem can support both a standard server-based computer network interface and a network interface of the Jview ™ subsystem. Subsystem of events The subsystem of events is used to support the transactions that originate as a result of internal processing through an application's transaction logic. These transaction requests199they are processed in the background. For more information, refer to the "event management" section. Mail Subsystem The mail subsystem is used to support transactions that originate as a result of receiving an incoming email message. This subsystem validates that the incoming email message contains a valid security descriptor and will create an event that triggers the transaction request to process the data associated with the incoming email message. Batch Subsystem The batch subsystem is used to support transactions that originate as a result of a previously defined schedule. This batch programming is used to define "point-in-time" transaction requests. For example, this subsystem is used to activate a processing request that is to prepare a specific report every night. Message translation subsystem The message translation subsystem is designed to communicate with another external system that uses automated electronic interfaces. This subsystem can handle incoming and outgoing electronic messages. The messages200entrants cause the request for transactions that are processed through the TPL. Outgoing messages are generated in response to a specific event processed by the event manager. In general, this subsystem supports asynchronous messages (instead of synchronous messages). Transaction processing level The level of transaction processing is responsible for processing all transaction requests. For each transaction request, this level uses the system services to do the following: perform transaction security validation, block the folder (if necessary), validate input data (editing functions only), recover database objects, invoke validation related to the application data model (editing functions only), invoke validation related to the application transaction (editing functions only), create audit tracking events (only edit functions), invoke the alert manager to evaluate the application's business rules and generate alerts (editing functions only), invoke the workflow administrator to evaluate and set the status of the workflow (functions only) of edition); save any new or modified data with the database; and release the folder (if it is201necessary). These services are described in more detail below in the "system services" section. Application logic For any given vertical market, the generic transaction processing capabilities of the system extend with the logic and configuration of the application that is specified in a given vertical market. These application extensions are what provide the system with its specific vertical market focus. As a result, the generic transaction processing system can service any number of vertical markets. The logic of the application consists of the following main parts. Unified data model Mentioned above, this is the data model that defines the entities and attributes that are specific to a given vertical market. Application logic, related model For each application-specific data entity, the application logic can be defined in relation to the validation and processing that is specific to this entity. Application logic - related to the transaction For each transaction specific to the application, the logic of the application can be defined in relation to the202validation and processing that is specified for this transaction. Configuration Many of the services processing of generic transactions are based on the definition of the information of external configurations. This configuration is defined for any vertical market (and allows the services of the generic transaction processing system to be customized for the specific needs of the vertical market). System services The various subsystems and levels described above are based on an enriched set of system services. Some of the main services include: blocking and reservation; graphic object services; administration of alerts and business rules; workflow management; security administration; individual property and equipment; external notifications; instant services; Preparation of reports and document management. These services are described in detail within the system's service processing section below. Prior art - recognition This structure of the application is based on services of the following technologies and recognizes any technique203previous in these domains.
This application structure builds the capabilities established by this technology and provides additional services and capabilities specifically aimed at processing transactions between organizations that are not resolved. This structure of a transaction processing system based on general computer networks and the role of the structure of the application within this structure is illustrated in Figure 28. This structure closely relates to the previous description of the Jview ™ subsystem and the administration of the workflow between administrations. Commercial Example The electronic subrogation network is a commercial example of a complete operating system that represents the concepts described herein specifically for the vertical market of claim processing.204Subrogation in the insurance industry. Terminology This section contains terminological definitions that are useful for understanding the concepts described in this section. Folder Each different business transaction is represented by a folder. The folder is used to logically contain all the information related to this transaction (for example, parts, tasks, documents, contacts, alerts, attachments, events, etc.). Part A business transaction involves the interaction between two or more parties where, for purposes of the transaction, each party develops a specific relationship (described below). With the workflow within the organization, the parties typically are different business units (eg, division, department, etc.) within the same organization in the work flow between organizations, the parties typically being different organizations or individuals. Relationship (part type) For each specific type of business transaction (folder), one or more relationships are defined. Each relationship defines the role that a particular party performs with205with respect to said transaction. For example, in a simple order management transaction (order folder), one party represents the "buyer" and another party represents the "provider". In this way, for each part defined in the folder, that relation of the part with the transaction is called as part subtype. Tasks A task is used to represent an independent business activity (related to the transaction for this folder). Each folder must have at least one task (its main task). With complex business processes, multiple tasks are used within the portfolio to manage and track parallel multiple activities related to a particular business transaction. For example, for an order management transaction (order folder), a task is defined for the same order, and additional tasks are defined for each different shipment / invoice. Action part For each task in the folder, the party responsible for carrying out the following action related to that commercial activity is called the action part. When the commercial transaction is concluded, there is no greater commercial activity. At this point, no action part exists in the tasks within the folder.206Function Every operation that can be performed in the folder, which affects the information or status of the folder, is called a function, based on the folder, certain functions can be performed through a specific part type, while others can be performed by some or all party types. In a simple order management transaction, some examples of functions include: issuing a purchase request (buyer), accepting an initial request (provider), creating a shipment / invoice (provider), etc. Two types of main functions exist, editing functions and non-editing functions. The editing functions cause the modification of commercial data within the database; the non-editing functions are not (that is, the essential non-editing functions are only used to recover data). The definitions of the functions are contained within the system configuration tables. Each function definition contains configurations that control the processing of transaction requests (for example, type of edition, type of part, specification of object graph, etc.). The collection of function definitions within the system are specific to a given vertical market and essentially define the commercial processing capabilities of the system.207Organization Two different legal entities (for example, company) opposed to different commercial units (of arbitrary size) within a single legal entity. Workflow A set of business operations and / or defined processes, activated by an initial commercial event (commercial transaction), which continues in a specific sequence or body and ends in a conclusion or termination of the transaction. A simple workflow follows a prescribed set of operations in sequence to the conclusion (single path). A complex workflow contains multiple conditional routes, only one of which is taken based on the commercial conditions present in the transaction. Workflow between organizations A workflow that exists between two organizations in order to complete / complete a specific business process / transaction for those organizations. Object Graphic Specification (OGS) A set of configuration data that defines the set of data entities and attributes and their object structure, is used for a determined transaction request (ie, function), the TPL uses the OGS to ensure that a particular party can only send or receive items of208data allowed for your part type. Additionally, this mechanism can also be used to further restrict access to the data based on the specific role of the user (within a part type). Paper A set of configuration data that defines a group of functions. The resulting set of functions can then be associated with an automated operator or system. Security management services use the definition of paper to limit the functions that can be performed through a given operator or system. DETAILED DESCRIPTION - Transaction processing between organizations The inter-organizational transaction processing system (referred to as the application structure or only A / F now) consists of an application structure designed to cover the requirements of transaction processing between organizations (mentioned in previous paragraphs). This structure does not depend on any specific vertical commercial process or application and is unique in its ability to deal with multi-part transactions that expand in different organizations. This section contains detailed processes and209descriptions of components related to the A / F. This analysis assumes a familiarity with the following concepts and technologies: Transaction-oriented transaction processing concepts in general; object-oriented design and programming; basic fundamental elements of the Internet. The A / F described in this section has been validated with the following contexts of vertical commercial application: Insurance - subrogation claims (claims, counterclaims, presentation of arbitration, etc.); manufacturing - processing requests (purchase request, shipping, billing, returns, etc.); retail sale - store management (work scheduling, employee maintenance, follow-up clock monitoring, etc.); and general - call log and problem management. Overview Model and structures of the central object The A / F includes a central object model that provides a set of fundamental classes and data entities that are used to build applications. Objects centered within this model are typically used in most applications. Additional, specific objects210to A / F, they allow the system to perform its control operations within the context of transaction processing between organizations. When building an application, these objects can be used as they are or can be subclassed to support application-specific extensions. Objects within the central object model can be grouped into three main categories - transaction objects, configuration objects and system objects. Transaction objects represent the control structures of the application or transaction within the business transactions that are processed in the system. The configuration objects represent the configuration structures used by the A / F at runtime, this defines the specific processing characteristics of each vertical application. The system objects represent internal system structures that are used to control the internal operation of the system.211O tra csa ction objectsName of entity / class Abstract SAFolder Abstract. The generic container for all data related to a particular transaction. SAFolderData Abstract. This class is used to support the specific extensions of an application in a folder. SAParty The organization or individual involved in a particular transaction. SADocument Abstract. A set of structured data elements related to a transaction.
Abstract SAAttachment. A set of related metadata about a set of unstructured data (see SAAttachmentData). SAAttachmentData A set of unstructured data related to a transaction (for example graphics, photos, etc.). SAComment A comment of free form related to a document within a transaction. SAContact A set of name and / or address information related to a contact within a transaction. SADocContact A relationship object that connects a document to a contact. SAAIert A commercial condition that exists with a certain transaction. SAEvent Audit information that provides a record for each modification in the contents of the folders. SASnapshot A large binary object globular (BLOB) of information that contains a complete set of information of the folder at a given time (ie, an instant photograph). This object is used to keep a historical record of all the modifications of the data in the folder. SATask A commercial activity that occurs within the folder.212Co nfig ration objects Organization / class name Summary SAFunction A function of the application (transaction) that is supported by the system (external). SAIntrinsicFunction A function of the application (transaction) that is supported by the system (internal). SAIntrinsic A primitive (intrinsic) transaction processing function supported within the classes of the programs and application programming systems. SACompany An organization or individual that can participate in transactions within the vertical application. SAGroup Within a company, a group or team of individuals in a location. SALocation Within a company, an office or physical location.
SAOperator Within a company, a person (or accountant) who has access to the system. SARole Within a company, a group of related application functions that are necessary to perform a specific job or function within the company. SARoleFunction Refers to a specific function of a specific role.
SAAIertRuleTemplate A template that defines a generic type of business rules that can be evaluated through the system. SAAIertRule A business rule that is used to evaluate a specific business condition for a specific company. SADocContactTemplate A template that defines a generic type of contacts in a document. SADomain A set of application-specific values that define a domain in the application. SAEventTemplate A template that defines the processing characteristics for an event. SAMessageTemplate A template that defines the processing characteristics for a message. SANotificationRule A system rule that defines the processing characteristics that are used to generate an external notification based on an event that happens. SAObjectGraphSpec In a transaction template, constraints, data entities, and attributes that can be exchanged / processed within a given transaction. SAWorkflow A template that is used through the workflow manager to control the workflow of a transaction folder. SAWorkflowRule A company-specific workflow rule that is used by the workflow administrator to perform a workflow within the company. SAWorkfiowRuleTemplate A template that defines a workflow function specific to the generic company that can be performed through the workflow manager.213System objectsFolders and documents Within the A / F, the folder is a key concept. An example of a folder object exists for each different application transaction within the system. Different types of transactions are supported by different types of folders. A generic folder class (SAFolder) is provided through the structure of the application. This abstract class contains all the data elements and the methods that are used in the structure to manage the transaction in a generic way. Specific application folders are created through a sub-classification from their root class. In this way, any number of application-specific folders will be214can create (one for each type of application transaction). The folder is a logical container for the following collections of data related to the transaction: Parties - where a party is an organization or individual involved in the transaction; documents - where a document is a structured data set; annexes - where an annex is a set of unstructured data; events - where an event is an audit trail of any data modifications in the transaction; alerts - where an alert is a commercial condition that exists within the transaction; contacts - where a contact is the name and / or address information related to an individual or organization related to this document; and tasks - where a task is a business activity that happens within the transaction. For each folder, the A / F can provide a number of common services. These services are supported through each folder declared in the specific subclass of the application that defines the specific folder. The following folder services are supported generically through215A / F: support for multiple parties, workflow support, blocking and reservation, alert management, event management, external notifications, document management (both structured and unstructured documents), and contact management. In addition to the folder, a document is another key concept within the A / F. Within a folder, a related set of business information is represented through the document (for example, within a manufacturing context, an application folder). contains the following documents, a purchase request, shipping notices, invoices and credit notes). A generic document class (SADocument) is provided through the structure of the application. This abstract class contains all the data elements and methods used throughout the structure to generically handle a particular document within a transaction. The documents of the specific application are created through the subclassification of this root class. In this way, any number of application-specific documents can be created. The document is also a logical container for the following collections of data related to the document: DocContacts, where a document contact216connect that document to a specific contact within the folder, and Comments, where a comment is a free-form note related to this document. Architecture of the structure of the application The structure of the application consists of a tiered architecture (as illustrated in Figure 27). This architecture consists of the following levels: a level of the interface subsystem, a transaction processing level (TPL), a logical level of application and system services. Processing with each of these levels is different as described below. Processing of the interface subsystem Within the A / F the interface system level is responsible for exchanging the transaction requests and their responses with the external environment (usual interactive, other automated systems, electronic messaging networks, etc.). In doing so, it essentially performs a function control function within the architecture (that is, managing a transaction processing session with each different external environment). This level consists of the following differentiated subsystems: online subsystems (OLS), subsystem of events, subsystem of mail and subsystem of translation of messages.217Online subsystem The online subsystem processes all request / respond to interactive users based on the computer network. The OLS is designed to work with the Jview ™ subsystem (within the search engine) but can also support the generation of server-based HTML through the HTTP subsystem. In any case, the transaction message (STM) is used as the request / response format for the OLS. The OLS consists of one or more examples of processes(which run on one or more application servers). Each process example is capable of HTTP requests. When a given process instance creates a session for a particular user, all requests for that session are processed through a process example. Next, the main processing performed within the subsystem is described. Establishing an OLS session (system entry processing) Before any transaction can be processed, a user must first establish a session with the OLS. Then a request to enter the initial system is sent. The OLS responds with a form of system entry (HTML). The user then enters his company identification, user ID and password and218presents this application to the system. If a security is indicated in the IP subnet, based on the identification of the company and the IP address of the incoming request, the system validates the IP subnet for this request. If the IP subnet is valid, the system validates the user's identifier and password for this specific user within the specific company. If the user is valid, an OLS session is created. This session is used to maintain a context about the current state of the user's interactions with the system. By default, a subsession is always created when a new session is created. The subsession represents a communications channel to make a single transaction request at a time (multiple transaction requests can be made in parallel using multiple subsessions). After creating the session, OLS creates an instance of the transaction manager (SCTranMgr). This object is used to control globally all transaction processing that happens within the session. This is one of the main objects that represent the TPL. Within the subsession, a stack is created. The stack is used to track requests for related transactions that occur in a nested manner. The operation of the stack is described later. Based on the user profile, an initial (default) transaction is made when creating219a stack entry and invoke the transaction processing level (TPL). This process is described in more detail below. The results of this initial transaction are then sent to the user in response to his request to enter the system. Processing a transaction request Once an OLS session is established, transaction requests / responses can be processed. A transaction request is received through the OLS as a standard HTTP request (obtain or publish). Within this HTTP request a variable FORM or CONSULTATION contains the transaction request message in the form of a transaction message (STM). As in the XML, the STM represents the stream of thinned object (that is, a serial stream) consisting of a hierarchical structure of clavervalor pairs (where each node in the hierarchy represents an object). The STM consists of two main sections - subject of STM heading and commercial. The OLS converts the STM into an object format using a generic object class (SCObjectGraph) -called OG. If security is indicated in the IP subnet, based on the company identifier and the IP address of the incoming request, the system validates the IP subnet for this request. Once in the object format, the OLS inspects the attributes of the transaction request contained in the220header. These transaction requests can be OLS commands or application function requests. OLS commands are used to perform stack control and assignment operations for the current session. Application function requests are used to execute application functions. Within the request header, the string type is used to control the stack within the session. For function requests, this type of string can be CHAIN__TOP (ie remove all stack entries and create a new initial stack entry) or CHAIN_NEXT (that is, create a new stack entry on the stack). Based on the type of string, a new stack entry is created. This data structure is used to anchor other objects related to these transaction requests. Based on the function (transaction request code) contained in the header, a transaction object (SCTran) is created by invoking the CreateTransactionO method to create a TranMgr transaction (created in the session). The name of the function passes as a parameter to this request and is validated through the TranMgr (this validation process is described later). The instance of this object is anchored in the stack entry for this request. When you create the transaction object, an instance is created for a specific transaction in the application. Each transaction class of the application is subclassified221from an SCTran. Each function is related to a specific application transaction class. In this way, when a CreateTransactionQ method is invoked, it creates the instance of the application-specific transaction class based on the function based on the method. After creating the SCTran object, the OLS establishes several attributes within this object that control the processing of this request (for example, OG, query parameters, transaction parameters, etc.). The TPL processes two main types of functions (transactions), editing and non-editing. Non-editing functions are read-only (that is, inquiry) that only returns information. The editing functions result in the modification of data within the database. The execution of a given request is determined through the subfunctions below (passes to the TPL through the OLS) -prepared, validated and committed. Non-editing functions only support the "prepare" sub-function. The editing functions support the subfunctions. Inside the stack, the OLS maintains the sub-function status of a certain function (mainly for editing functions). A finite state machine is used to control valid transitions from which subfunctions can be requested at any time within the execution of a request. For functions that are not editing, occurs222the next. The function is executed when invoking the ExecuteQ method of the transaction object that specifies the subfunction (prepare). Based on the prepare subfunction, the TPL invokes the prepare () method of the transaction object of the application to process this request (that is, retrieve the objects for this request). The TPL returns an output OG that contains the objects that have been retrieved for this request. The OLS converts this OG into an STM using this STM, the OLS generates an HTTP response in the initial HTTP request. For editing functions, the following occurs (full processing of an editing function typically involves several interactions with a user). The function is initially executed by invoking the Execute () method of the transaction object that specifies the subfunction (prepare). Based on the prepare subfunction, the TPL invokes the prepare () method of the application transaction object to process this request. If this function requires the input of a user, this method analyzes any business objects required for this transaction and the TPL returns an output OG that contains these initial objects for this request. If this function does not require the input of a user, the processing continues with step 8.g. The OLS converts these OGs into an STM. When using this STM, the OLS generates an HTTP response to the223initial HTTP request. Based on the response of the system, the user can make any modifications to the data (as the form admits) and present this modified data to the server. The OLS receives this new request. Based on the type of string (CHAIN_CONTINUE) and status information within the existing stack entry, processing of its editing function continues. Processing of that function now continues by invoking the Execute () method of the transaction object by specifying the "validate" subfunction. Based on the subfunction to validate, the TPL now invokes the validate () method of the application transaction object to process this request. This method performs the validation and processing of the application-specific data related to the request. Upon completion of this processing, all business objects are updated in memory and are not yet written to the database. The TPL returns an output OG that contains the updated business objects. If the validation is not successful (that is, errors are detected), the OLS discards the new OG and returns the previously received OG entry (received in step 8.e) to the user with the associated errors. At this point, the user is allowed to make the modifications / corrections of the data (if the form allows it). At this time, the224processing returns to step 8.d. The validation is satisfactory (that is, there are no errors), OLS converts that OG into an STL. When using this STM the OLS generates an HTTP response to the initial HTTP request. This response allows the user to view, without modifying, the data and allows the confirmation of this transaction. Based on the response of the system, the user can view the proposed transactions and submit their confirmation. The OLS decides this new request. Based on the chain type (CHAI N_CO NTI N U E) and the status information within the entry of the existing row, processing of this editing function continues. The processing of this function continues when invoking the Execute () method of the transaction object by specifying the sub-function "assign". Based on the assign subfunction, the TPL now assigns any updated business object to the database. Doing so generates a termination message. The TPL returns an output OG that contains the updated business objects. If the assignment is successful, the OLS saves the termination message for the transaction. Then the input of the current stack is discarded (for the editing function that was processed) and the function associated with the input of the previous stack is executed again. The TPL processes this function and returns an output OG that contains the business objects for this function, the OLS225convert this OG together with the termination message from the previous editing function, STL. When using this STM, the OLS generates an HTTP response to the initial HTTP request. NOTE: For each application function request processed and before generating any HTTP response, the OLS invokes the TransactionStatisticsQ method of the TranMgr. When invoking this method, the OLS passes the transaction statistics data for the previous application function (the response time data was returned in the request header for the current request). This method causes TranMgr to update a statistical memory object (for the current session) with the new transaction data. This information is updated in the database when the session ends. Establishing a new subsession with a session Once an initial session is established, together with the default subsession, another subsession can be created in order to execute another application function without interrupting the stack or application functions that exist within any another existing subsession. A transaction request (STM) is received through the OLS and converted into an object format. Within the header, the transaction request is for an OLS (OLS_NewSubsession) command. The OLS then verifies the226current session identifier and the security code within the request header. If it is valid, a new subsession object is created and added to the list of subsessions for the current session. Within the new subsession, a stack is created. Based on the user profile, an initial (default) transaction is made when creating a stack entry and invoking the transaction processing level (TPL) (as described above). The results of this initial transaction are then sent to the user in response to his request to enter the system. NOTE: Within the search engine, each new subsession is presented through a new browser window. Termination of an OLS session (system exit process) Within the OLS, a session is terminated when the last subsession ends. Subscriptions can end explicitly with a request for "exit from the system" or implicitly after a "time out". For requests to exit the system, the following sequence occurs. The OLS receives a transaction request (STM) and becomes an object format. Within the header, the transaction request is for an OLS (OLS_Logoff) command. Based on the subsession for this request, the OLS: removes the stack from the subsession that is terminated (individually deleting each entry of the227stack inside the stack); and deletes the object of the subsession and removes it from the list of active subsessions for the function. If there are no more active subsessions for this session, the OLS: invokes the LogoffQ method of the associated TranMgr object within this session (created at the initiation of the session). This method causes the TranMgr to record response times and session statistics, collected during this session, within the database. Delete the session object (thus invalidating any additional requests for this session). A satisfactory system exit message is sent to the user in response to his request to exit the system.
For times out, the following sequence occurs. When the time period is for a subsession expires, the TimeOut () method of the object of the session is invoked (specifying the identifier of the relevant subsession). Based on the subsession, the OLS: removes the stack for the subsession that is ending (removes each stack entry individually within the stack); and delete the object of the subsession and remove it from the list of active subsessions for this session. If there are no more active subsessions for this session, the OLS: invokes the LogoffQ method of the associated TranMgr object within this session (created at the beginning of the session). This method causes the TranMgr to record any response time and statistics from the228session, collected within this session, within the database and deletes the object of the session (thus invalidating additional requests for this session). Event subsystem When processing each transaction request through the system, events are written to the event table within the database. The collection of events in a given folder forms the history of the business activity for that folder. The subsystem of events inspects the events that happen within the system and allows the system or the application to present a specific subsequent processing for each event. All events registered in the system are processed later through the event manager. For each event, this subsystem does the following. Determines if any subsequent processing is defined for this event, if so, activates the specific function to perform this processing (NOTE: This processing is done in the background). Determines whether external notifications are defined for this event, if so, invokes the external notification administrator to process external notifications. For more information, see the "external notifications" section. Determines whether outgoing electronic messages are defined for this event, and if so, invokes the message translation manager of229output to generate the electronic messages. For more information, see the section "message translation". For each event, an event template definition is contained in the system configuration. This definition contains configurations that control the processing of this event through the event manager. From a multi-part perspective, each event contains information that defines the types of parties that are allowed to access this event. This allows the system to expose and hide various events for specific parts within the folder based on the type of event. Essentially, the event management services provide a follow-up of audits that maintain the system on all data modifications that occur within the system. By centralizing this service, all data modifications that occur within the system can be inspected, and if necessary, additional processing can be invoked. A unique aspect of this service is the ability to manage multiple parts. The event subsystem consists of two main components, the SAEvent object (and related methods) and the event manager. An application transaction230create an event by using the CreateEventO class method of the SAEvent class. The event manager consists of one or more processes in the background (running on one or more application servers) that retrieve the unprocessed processes from the event table and processes each compliance event. When creating an event, the CreateEventO method uses the event template (for this event) to determine if any further processing should occur for this event. If not, the attribute "processed" is set to true. This optimization prevents the event manager process from retrieving this event from the database (that is, only to discover that it does not need any processing). The main processing performed within this system is described below. Event Manager-Initiation Each process of the event manager performs the following initialization sequence. Read all configuration values (for example, the time to deactivate when no work is done, etc.). Create an instance of the transaction manager object (SCTranMgr). This object is used to coordinate the processing of the functions of any application that are activated through the production of specific events. Create a Java braid that continually "queries" the database by searching231unprocessed events. Complete the necessary initialization to handle HTTP requests. This process supports the ability to receive special administrative requests to control the process (for example, shut down). It does not support the ability to process requests from the application function (similar to the previous OLS). Update the system registry with a registration message "initialization of event management". Event Manager-request processing cycle The request processing cycle occurs continuously within the event manager (until it ends). During the processing cycle the following operations are carried out. Find if the event manager should end, that is, bTerminateEvMgr = True (as set by the administration HTTP request). An SQL query is used to obtain a single folder of the database with the following conditions. The folder is not locked and background processing for this folder has not stopped and the folder contains one or more unprocessed events. If it is not returned in a row, then the process "deactivates" for n seconds (as determined through the configuration). Upon awakening, step 1 is repeated. If a row of a folder is returned, then continue. Lock232Folder. If the blocking operation is not successful, then repeat step 1. Otherwise, continue below. Check the database for unprocessed events for this folder (sorted in ascending order by date / time of occurrence). Select the first row of the result set for further processing. If it is not returned in a row, continue with step 10. Obtain the event template associated with this event. This template indicates whether the following operations should be performed; external notification processing, external message processing, subsequent processing of the application. If external notification processing is indicated, do the following. Invoke the GenerateNotifications () method of the external notification manager (ExtNotifMgr) by passing a reference to this event. The ExtNotifMgr queries the database to obtain all the external notification rules for this type of events (based on the parties involved). If there are specific rules of the party, those rules exceed all other rules; otherwise, generic rules are used. If there are no rules for this type of events, then no external notifications are made. The ExtNotifMgr then processes each external notification rule as necessary. Each rule refers to a contact within233of the folder (based on the type of generic contact). If there is no specified contact within the folder, then notifications are not issued. If the contact exists within the folder, then ExtNotifMgr retrieves the contact information of this specific contact for the notification method specified in the notification rule (for example, email, fax, search engine, etc.). if there is no such information, then no notification is issued. If the information required to generate the notification exists, then the notification is issued. If an external message processing is indicated, do the following. Invoke the GenerateMessages () method of the message translation manager (MTMgr) by passing a reference to this event. The MTMgr queries the database to obtain all the rules of the external messages for this type of events (based on the parties involved). If there are specific rules for this part, those rules exceed the other rules; otherwise the generic rules are used. If there are no rules for this type of event then no external messages are generated. The following is done for each external message rule. The external message rule invokes the outgoing message formatter to construct an XML structure that contains the outgoing message data. The structure of the XML message is written to the outgoing message table2. 3. 4within a separate database for the integration server. The integration server retrieves the structure of the XML messages from the outgoing message table and converts it into a native format as indicated by the message header. This subsystem then uses the appropriate protocol (for example, TCP / IP, FTP, HTTP, SMTP, etc.) to communicate this message to the external system that will receive this message. If a post-application processing is indicated, review the following. Obtain the function that will be executed from the event template for this event. Invoke the BGLogon () method of the TranMgr object to initialize the transaction processing context for the company that created the event. Based on the function (the transaction request code), a transaction object (SCTran) is created by invoking the Createtransaction () method of the TranMgr (created during the initialization of the event manager). After creating the SCTran object, the EventMgr establishes several attributes within this object that control the processing of this request. The function of the application is executed by invoking the ExecuteQ method of the transaction object by specifying the sub-function of "assign". Based on the assign subfunction, the TPL does the following. Invokes the prepareQ method of the object235application transaction. Invokes the validate () method of the application transaction object. Invokes a call to the EventMgr to allow specific data modifications to be included in the event manager (for example, update the process indicator within the current event that is in process). If there are no errors, call the commit () method of the application's transaction object. This causes all the data processed during the function to be written to the database. If there are no errors during calls from the previous methods, the TPL returns to a "satisfactory" state. Otherwise, an "error" status is returned (for any method where an error is detected). If an error status is returned, the event manager stops background processes for this folder by setting an appropriate flag in the folder and assigning this change to the database. If it is returned to a satisfactory state then the event manager goes to step 5 and continues with the processing of the unprocessed events remaining for this folder. When there are no unprocessed events for this folder, the folder is unlocked. Continue with the processing cycle when you return to step 1. NOTE: A unique feature of external notification processing and external messages is the236ability to send one or more messages to each part defined in the folder. This capability is based on the interorganizational architecture inherent within the system. Event-termination manager The event manager continues with its request processing cycle until it ends. The event manager may terminate when terminating a process externally or through an HTTP request. If an HTTP request is received to terminate the event manager, this request sets the variable bTerminateEvMgr = True to be true. When returning to the start of this normal processing cycle the event manager checks this variable and ends (thus allowing the completion of any processing for a given folder). The event manager performs the following operations during termination: it deletes the TranManager instance, updates the system registry with a registration message "termination of the event manager", then performs the termination of the event manager process. Mail subsystem (incoming mail processing) This mail subsystem is designed to process237incoming mail messages. Each incoming mail message contains a special subject line and a message body (in addition to the attached files) to allow the system to determine the type of processing that is required. The mail administrator is the main component of the mail subsystem. Typically, there are two instances in the mail manager process (running on different application servers within the network), one process is active and the other is inactive. Next, the main processing performed within the subsystem is described. Mail Administrator-Initialization Each process of the mail administrator performs the following initialization sequence. Reads all configuration values (for example, number of seconds to be inactivated when no work is done, etc.). Create a Java braid that continually "queries" POP3 mail servers for incoming mail messages. Complete the initialization needed to handle HTTP requests. This process supports the ability to receive special administration requests to control processes (for example, shut down). It does not support the ability to process requests from the application function (similar to the previous OLS). Update the system registry with a registration message "initialization of the238mail administrator. "Mail Manager-incoming mail processing cycle The incoming mail processing cycle occurs continuously within the mail administrator (until it ends.) During this processing cycle, the following operations are performed. It checks whether the mail administrator should end, that is, bTerminateMailMgr = True (as set by the administration's HTTP request.) Locks the MailManager resource (using the lock manager), if the lock operation is successful , then proceed to step 3. Otherwise, the process "will be disabled" for N seconds (as determined by the configuration). When activated, go back to step 1. This serial order only allows a process of the postmaster be active (that is, consult the mail server) at any time and avoid stopping the processing of an email message caused by an admin active mail carrier stuck or frozen for some reason. The other processes continue the query trying to acquire the blockade (essentially remain inactive until they acquire the block). This process acts as a failed process that is activated when the mail administrator process fails or clogs239active. NOTE: When this operation is done through the active mail manager process, it works to "regenerate" the blocking. When using the configuration values obtained during initialization, enter the system of the first email account for the specified POP3 mail server. Obtain the following email message, if any, from the account. If there are no messages within this account then proceed to step 7. Each mail message is processed as indicated below. Analyze the email message in its main sections (for example, subject, body, attachment). Explore the body of the message looking for the specially coded section. This section contains 1) the folder that will contain this email, 2) a unique sequence number for this message and 3) a reference to the event template that will be used for this message. Invalid messages are temporarily stored for review, then discarded. For valid messages, the folder reference and sequence number are used to query the database and inquire whether this message (SAMailMessage) already exists within the system. If so, it has already been processed, continue with step 5J below). Block the folder indicated by this email message. If the blocking operation is240satisfactory, then continue with step 5E. Otherwise, skip this mail message by going back to step 4 (this message will implicitly try again in the next cycle). Create an instance of a SAMailMessage object that contains the data of the new mail message. Create an event (based on the decoded event template within the message) for this folder that references the newly created mail message object. Assign these objects to the database. Unlock the folder indicated by this email. Delete this mail message from the mail account of the POP3 mail server. Return to step 4 to process any remaining mail messages in this account. Based on the configuration, obtain the following email account from the configuration. Return to step 3 to process the messages for the new email account. When there are no more pending email accounts continue. At this point, all mail messages in all accounts have already been processed. The process "deactivates" for N seconds (as determined in the configuration). Upon re-activation, continue the processing cycle by going back to step 1. Mail-termination manager The mail administrator continues in its cycle241processing requests until it ends. The mail administrator ends by terminating the process externally or by an HTTP request. If an HTTP request is received to terminate the mail administrator this request sets the variable bTerminate ail gr = True to be true. When you return to the beginning of this normal processing cycle, the mail administrator checks this variable and finishes it (this way it allows to finish the processing of mail messages that are currently in process). The mail administrator performs the following operations during the termination: it updates the system registry with a registration message "mail administrator termination" and performs the completion of the mail administrator process. Message translation subsystem The message translation subsystem is designed to communicate with other external systems using automated electronic interfaces. This subsystem can handle outgoing and incoming electronic messages. Incoming messages cause requests for transactions that are processed through the TPL. Outgoing messages are generated in response to a specific event processed by the event manager. In general, this subsystem supports asynchronous messages (instead of messages242synchronous). Essentially, the message translation system is used to process incoming and outgoing electronic messages. This service allows a technologically sophisticated organization to process business transactions in a fully automated way, even when their counterpart organizations interact with a manual basis (using interfaces based on electronic networks). The message translation subsystem consists of the following main components-integration servers, incoming message translation processes, and outgoing message translation services. The integration server provides a direct interface with each external system handling a variety of communication protocols and data formats required by the systems. By doing so, it isolates the entire system from the details of the interface and provides a common interface mechanism for all electronic messages. To maintain high availability, the integration server interfaces with the system by storing / retrieving all messages from the database server in an XML format. In this way, other parts of the system can be stopped without affecting the ability of the system to receive messages from another system. Within the system, the server243Integration is a standard component that is commercially available (for example, WebMethods, BizTalk). The incoming message translation (IMT) component handles all incoming electronic messages from the integration server (through the database). This component consists of one or more process instances (that run on one or more application servers). Similar in structure to the event manager, these process instances continually query the database for new incoming messages to process. The outgoing message translation component (OMT) handles all outgoing electronic messages. These messages are generated in response to an event (based on the specifications within the event template for that event). This component is a service that is invoked within the context of an event processing performed by an event manager process. The main processing performed within this system is described below. Processing incoming messages-general description The following operations are performed during the processing of incoming messages. An external system establishes a connection to the integration server. This244Connection varies based on the protocol and the nature of the specific interface. In general, this connection can be used to transmit a transaction file, a set of individual transactions or just one transaction. The integration server receives an electronic message from an external system over the established connection. Based on the message correlation rules contained within the integration server, this server converts the incoming electronic message into an STM format (Siteras transaction message) into an XML syntax. This message is stored as an object (SAInboundMessage) within the table of incoming messages within the database server (database of the integration server). The IMT process processes the incoming messages that have been queued in the database. The detailed operation of the IMT process is described in the following sections. IMT-initialization process Each incoming message translation process performs the following initialization sequence. Not all configuration values (for example, number of seconds to deactivate when no work is done, etc.). Create an instance of the transaction manager object (SCTrarManager). This object is used to coordinate the processing of application functions that are activated when an incoming message arrives. Create a braid245Java that continuously "queries" the database (the table of incoming messages within the integration server database) looking for incoming messages. Complete the necessary initializations to handle HTTP requests. This process supports the ability to receive special administrative requests to control the process (for example, shut down). It does not support the ability to process requests from the application function (similar to the previous OLS). Update the system registry with a registration message "initialization of the translation of an incoming message". IMT process - message processing cycle The message processing cycle occurs continuously within the IMT (until it ends). During this processing cycle the following operations are carried out. It checks if the IMT will be terminated, ie bTerminatelMT = True (as established by the HTTP administration request). Check the database and retrieve the incoming messages available. If there are no messages available, this process "deactivates" for N seconds (as determined in your configuration). When activated, the process restarts in step 1. If a message is retrieved, processing continues. Based on the message identifier generated from the server and integration, this process attempts to block this message246using the resource identifier "I BMsg_ <msgid>". This blocking ensures that only one IMT process instance works on a given message at a time. If the block is not successful (which means that another IMT process is already processing this message), the process restarts in step 1 above. Otherwise, the block is satisfactory and processing continues. The IMT extracts this STM (XML message) from the SAInboundMessage object and converts it into an object format using a generic object class (SCObjectGraph, referred to as the OG). Once in the object format, the IMT extracts the function from the request attributes contained in the header. Based on the function (transaction request code), a transaction object (SCTran) is created by invoking the CreateTransaction () method of TranMgr (created during IMT initialization). After creating the SCTran object, the IMT establishes several attributes of this object that controls the processing of this request. The function of the application is executed by invoking the Execute () method of the transaction object that specifies the sub-function "assign" (for editing functions). Based on the assign subfunction, the TPL does the following. Invokes the prepare () method of the application transaction object. Invokes the validate () method to validate the transaction object of the247application. Invokes a return call to the IMT to allow any IMT-specific data modifications to be included (for example, the update of the processed indicator within the current message that is being processed). If there are no errors, invoke the commit () method of the transaction object of the application. This causes all the data processed during the function to be written to the database. The TPL returns a statement of results (either "satisfactory" or "ERROR"). If a response message is generated as a result of this transaction, then the outbound message may be triggered from the event that is recorded as the result of the processing of this transaction request (as described below in processing outbound messages) . If an error status is returned, the IMT stops processing for this message by setting the appropriate flag and assigning this change to the database. If a successful state is returned, the IMT will unblock the message and continue the processing cycle by returning to step 1. Processing outbound messages Processing outgoing messages occurs as the result of event processing by the event manager when The event template for this event specifies "message processing248external. "In this case, the following operations occur: If" external message processing "is indicated through the event template for the current event, the event manager invokes the outgoing message translation service (OMT) (passing a reference to the event.) By using the event template identifier from the event, the OMT will obtain the processing rules for outgoing messages for this event.When using these rules, the OMT constructs an output OG based on The content of the current event object The OMT then invokes the ConvertToXML () method of the OG object to produce an XML flow: the OMT creates a new output message object (SAOutboundMessage) that contains the output STM (in XML format) The integration server continually queries the database for outgoing messages.When an outgoing message is retrieved from the database it is converted to a native format (specific to the target system) based on the message correlation rules contained within the integration server. If a connection to the external system does not already exist, the integration server establishes a connection with the external system. This connection varies in accordance with the protocol and the nature of the specific interface. In general, this connection can be used to transmit a file of249transactions, a set of individual transactions or a single transaction. The integration server then transmits the native message to the external system. Once transmitted, the integration server continues its outgoing message processing cycle by continuing with step 6. Processing the transaction processing level (TPL) The transaction processing level is the center of the A / F and coordinates the Processing of application transactions within the system. A key part of this processing is the inter-organization validation that occurs for each transaction. In addition to validations of operator and basic company security performed by most systems, this complex validation ensures that the organization is authorized to perform this transaction along with various dimensions (for example, relationship, workflow status , etc.) This stage consists of two main components, the objects of the transaction manager (SCTran Manager) and transaction object (SCTran). Concepts of TPL The concepts and specific objects are very important for the operation of TPL. This section provides a general description of these concepts and250objects. Intrinsic Each application function is defined through a related set of three objects. The intrinsic object is defined first. This object represents a specific application function that has a hard code within a specific application transaction class (that is, an intrinsic function). An application transaction class can support one, or multiple, intrinsic functions. IntrinsicFunction Once a set of intrinsic objects is defined, a base set of the application functions is defined using IntrinsicFunction objects. Each IntrinsicFunction object defines a different application function and refers to a specific intrinsic object. This object establishes several parameters and values that control the processing of the transaction. Some of these parameters can be annulled and / or further restricted through the specific functions of the client. Because the intrinsic functions are inherent to the application, the workflow engines of the community refer to these objects when the evaluation of the workflow status between the organizations changes. Function Once the set of objects is defined251IntrinsicFunction, a custom set of functions of the application is defined using function objects. Each function object refers to an IntrinsicFunction object. At least, a function object is defined, by default, for each IntrinsicFunction. Additionally, a function object allows the addition of specific functions of the organization, these functions can override or extend the predetermined set of functions. This allows organizations to further customize the operation of a particular function to meet the specific needs of their organization (within the restrictions set by the related IntrinsicFunction). For example, a specific function of the organization can be used to display a different form / form for the user (one where the data elements have been deleted or have the default value, ie they are additionally restricted). Additionally, the specific functions of the organization are often defined to control the specific work flow of the organization (that is, work flow within the organization). Each transaction processed by the TPL specifies a function identifier. This identifier uniquely identifies the function object that contains the processing specifications for this transaction. Because each function is related to a function252Intrinsic, and each intrinsic function is related to an intrinsic, the attributes of all the objects provide the complete vector of the processing specifications for this transaction. Instead of referring to each of these objects individually this set of information simply refers to a vector of function, function or application function. Specifications of the object graph (OGS) and hierarchy of the transaction object The commercial objects stored within the database are related to a network structure. However, within the context of a transaction in a given application there is a different transaction object hierarchy that establishes a hierarchical relationship between the business objects involved in the transaction. The business object at the top of this hierarchy is called the root object. Within the A / F the specification of the object graph (OGS) provides the definition of the object hierarchy for a given transaction. An OGS object is defined for each function within the system. Each function can have its own different OGS object or multiple functions can share the same OGS. The OGS provides the structure and attributes of the processing for the transaction. A base OGS object is253define for each intrinsic function. This OGS works to restrict the function object. Additionally, another OGS can be defined in the object of the function, however, by making them this OGS can only restrict the OGS inherited from the object of the related intrinsic function. Object of the transaction manager (SCTranManager) In the transaction management (Tran gr) it represents a transaction processing context, (or session) in which one or more transactions can be executed. The Logon () method of this object is used to provide additional context information specific to a given company and operator. The main processing performed within this object is described below. Processing to enter the system The processing to enter the system occurs after representing a TranMgr object. The representation of the object performs a small initialization in itself. The main initialization of the TranMgr occurs in response to the invocation of the Logon () method as indicated below. A call subsystem represents a TranMgr object (class SCTranMgr). The Logon () method of the TranMgr object is then invoked. There are several tastes for this method (ie one254entry to the online system, an entry to the system in the background, etc.), but all pass the following key parameters for this method, company identifier, operator identifier, IP address and password. This method does the following. When using the company identifier, retrieve the company object (SACompany) from the database. If it is not found, it returns an error. When using the company object and the operator identifier (SAOperator) of the database. If it is not found, an error is returned. When using the operator object and password, the password is validated using the MD5 algorithm (one-way encryption). If it is not valid, it returns an error. For entries to the system in the background, a password is not provided, since this is a process of entering the internal system used by the event manager. Additionally, when the system entry errors are detected, additional processing is performed to track the type of error, its frequency, etc. Based on this information, the system temporarily or permanently disables the entry process to the system for the specific operator. By using the operator object, the role of the operator is obtained. The paper defines the functions of the application that this operator can perform (as defined through this255company). When using paper, the set of paper function objects (SARoleFunction) is retrieved from the database and placed in a buffer inside the Tran gr. Based on the objects returned from the database (for example, company, operator, etc.), several attributes are established within the TranMgr that represents a state "connected in the system". A new statistical object (SAStatistics) is created and anchored within this TranMgr object. This object is used to collect the sessions and transaction statistics for any transactions associated with this TranMgr. Based on a successful system entry, the invoke subsystem continues with the necessary processing after entry to the system for the subsystem (as described in the interface subsystem section). NOTE: The TranMgr object only represents a company / operator at a specific time. However, this object example can be reused in the sense that the Logoff () method re-establishes this object in preparation for another entry to the system. Processing to exit the system Processing to exit the system resets a TranMgr object (which was connected to the system). This processing is activated by invoking the Logoff () method of the TranMgr object. In doing so, the following occur256operations. A statistical record of sessions is created (based on the current statistics object for this transaction manager). A transaction statistics record is created (based on the current statistics object for this transaction manager). These records are assigned to the database. The attributes of the Tran gr representing the state "connected to the system" are restored. Creation of a transaction object Each of the application functions executed within the system requires a transaction object (SCTran). Instead of representing this object directly, this object is waxed through the TranMgr as a result of invoking the CreateTransaction () method. When this method is invoked, the invocation subsystem passes the function identifier of the function of the application (transaction) to be executed. Within this method, the following operations occur. The function identifier validates compared to the list in the buffer in the paper function objects (that is, if this operator has permission to perform this function). If it is not valid, an error is returned. Based on the function identifier, the function object (SAFunction) and the related objects (UPS ntrinsicFunction and SAIntrinsic) are retrieved from the database. If the type of257Part defined in the object or function does not correspond to one of the types in the Tran arrangement of the allowed part types within the company's object, then an error is returned. Each function defined within the system is intended to be performed under a certain "relation" (ie, the type of part). This variation ensures that the organization that makes the transaction is allowed to assume this relationship. When using the transaction class defined in the function object, the transaction manager creates an instance of the transaction object specific to the application. A reference to this object is invoked. Transaction object (SCTran) All the functions of the application that are executed within the system require a transaction object (SCTran). The SCTran class is an abstract class and is subclassified by each application transaction class. In this way, when creating the transaction object, an instance of a specific transaction of the application is created. A transaction object is created by invoking the CreateTransaction () method of the TranMgr object. The identifier of the function passes as a parameter to this request and is validated through the TranMgr (described above). A specific transaction class of the application is defined within each function object. This258Thus, when the CreateTransaction () method is invoked, an instance of the application-specific transaction class is created based on the function identifier. General description of the transaction execution The general execution of a transaction is a complex process that involves an ordered series of validations and subprocesses. Additionally, based on the nature of the transaction, this processing can be carried out in one or more transactions with an external system or with an interactive user. This section provides an overview of the processing that occurs during the execution of the transaction. This general description is followed by additional sections that detail the operation of several subprocesses. In general, the TPL processes two main types of functions (transactions), editing and without editing. Non-editing functions are read-only (for example, queries) that merely return information. Non-editing functions can be further classified as form or form functions. The form functions return a composition of many complex business objects. The form functions only return a single complex business object. The editing functions cause the modification of the data within the database. By definition, editing functions only work as a single business object. The editing functions259additionally they are classified in one of the following; insertion, update or deletion functions (based on the operation performed on the root object for the transaction). For each transaction the TPL defines the following processing phases for each transaction, the TPL defines the following main processing phases. Preparation (Prepare) During preparation, existing objects needed to process this transaction are retrieved from the database, new objects are created and initialized and any other initialization or processing specific to the application is carried out. This phase results in an edit context containing initialized application objects. These objects can be used merely to show information to the requester or they can represent a set of information presented to make further modifications. Validation (Validate) During validation, any data entered is validated and applied to the objects within the editing context (it is returned at the end of the preparation phase). After the input data is applied, a validation and order processing sequence is produced using the object hierarchy for this transaction as defined within the OGS. This sequence of processing260performs the specific validation or processing for the application for the transaction. Upon completion of this sequence, the TPL performs its final central services, generation of alerts, evaluation of the workflow status, generation of events and generation of term messages. If errors are detected, the editing context containing the objects is returned to the state that existed at the end of the preparation phase. Otherwise, this phase causes an editing context that contains the application and system objects that reflect the results of the specific processing for this transaction (ready to be assigned to the database). Assignment (Tran) during the assignment, the application and system objects within the editing context (which were modified) are written to the database. For non-editing functions, only the preparation phase is allowed. All phases are required for editing functions. A transaction is made by invoking the Execute () method of the Tran object for this transaction. Before invoking this method, the following input attributes of the Tran object are established. Root object This is a reference to an existing business object. If the function is a function to insert, then this parameter261it will be null Root object class The application class of root objects. Transaction parameters (TranParms) A set of application-specific parameters that are used to further control the processing of the application function. Input OG A reference is made to an OG object that contains the input data for this transaction. Query parameters For non-editing functions, it is a reference to an object of the query parameters. This object contains query parameters that are used to control the selection of database objects (that is, similar to the ON WHERE clause of an SQL query).
Subfunction The execution phase that is carried out, preparation, validation, assignment. Upon returning from the Execute- () method. The following output attributes of the tran object are returned. Outgoing OG It is a reference to an OG that contains the business objects resulting from this request (as controlled by the OGS for this transaction). For non-editing display functions, this OG consists of a262zero matrix for many complex business objects. For the other functions. This OG consists of a single complex business object. Data flow Instead of generating an output OG, some application transactions produce a binary data flow (the format and structure of which is defined within the function object). TPL Return Code The return code that indicates the status of the transaction processing, SATISFACTORY, ERROR, RETRY or FAULT. The meaning of these codes is as indicated below. SATISFACTORIO-indicates that the subfunction was performed satisfactorily by the TPL and no errors were detected in the application. In this case, the message matrix may contain one or more informal or warning messages. ERROR- indicates that the subfunction was performed satisfactorily by the TPL, but errors were detected in the application. In this case, the message matrix contains one or more error messages in addition to any information or warning message. RETRY-only for background processing, which indicates the subfunction is not complete and exists263a recoverable condition. The subsystem must retry this request later. The subsystem depends on the mechanism for making the retry. FAIL- indicates that the TPL encountered a configuration error or an unhandled exception during the processing of this request (which is retrieved from it) and records an event in the system. This request can not be processed Message matrix An array of message objects that contains one or more messages from the application. Each message contains a severity, information, warning or error. Below is a summary of the operations that occur when using this method and its parameters. The subfunction is validated based on the current state of the transaction and the type of function. For functions that are not editing, you can only specify "prepare". For editing functions, all sub-functions can be specified. However, depending on the status of the transaction, certain subfunctions are not valid. For example, if the completed transaction has a "validation" status, then it is not valid to specify the "preparation" sub-function. A finite state machine (FS) is used to ensure that the specified subfunction is264Valid for the determined transaction status. If the subfunction is not valid, an error is returned. Based on the passed subfunction, one of the following internal SCTran methods is invoked: _prepare (), _validate () or _commit (). Because the invocation subsystem can initially execute a transaction with "validate" or "assign", each of these internal functions checks the status of the transaction and invokes the method for an earlier phase if necessary. As a result, the transaction phases are executed in order, preparation, validation, assignment (with the exception of non-editing functions where only preparation is valid). The phases carried out never exceed the phase indicated by the subfunction. Once the phase or phases indicated by the subfunction are performed, the resulting editing context (managed by the Tran object) contains one or more commercial objects. By using this edit context and the OGS for the transaction, an output OG is created. The UpdateStatistics () method with the TranMgr object is invoked to update the transaction statistics for this request. The method then returns to the subsystem that invokes the output parameters described above. Preparation processing The processing that takes place during preparation varies based on the type of function performed.265For form functions, the following operations are performed. If the state of the Tran is "preparation" (that is, a "preparation" has already been performed), restore the Tran to the "Init" state. The selection criteria that are used to select commercial objects for the form are grouped as follows: the selection criteria are initialized to null; the query parameters of the intrinsic elements are placed in AND in the current selection criteria; the query parameters of the intrinsic functions are placed in AND in the current selection criteria, the query parameters of the function are placed in AND for the current selection criteria; and the query parameters that pass in the Tran object are placed in AND to the current selection criteria. The next hard coding query parameter is in AND in the current selection. This qualifier ensures that the SQL query only returns the business objects for which the current organization is authorized. This query parameter is very important to provide data security between organizations. This way MUST have a hard coding within the programs and programming systems and should not be modifiable through the configuration. The key conditions for this qualifier are summarized below. The organization that performs this function must be a part of the folder that266contains this commercial object. The organization that performs this function must have access to one or more tasks within the folder (that is, its third party must be included in the current part matrix for one or more tasks within the folder). The relationship of this organization for this transaction (that is, its type of part within the folder must correspond to the type of part of the function it performs)By using the selection criteria created above, the business objects are retrieved from the database (in accordance with these selection criteria) in the edit context associated with this transaction object. An output OG is created using the OGS for the function and business objects within the edit context. Establishes the state of the transaction in "preparation" sets the return code and any other output parameters and returns it to the invocation subsystem. For the functions of form, update and elimination the following operations are carried out. If the transaction status is in "preparation" (that is, a "preparation" was performed), reset the transaction to the "Init" state. If the function is an editing function or if the function is a function of form (with a value of, true blocking specified in the function), the folder containing the business object is blocked. If the blockade is not267satisfactory, an error is returned. If you pass a parameter of the root object, do the following. The root object and any other related objects (as specified in the OGS) are retrieved from the database. If the class of the root object returned does not match the parameter of the root object class then a FAULT is returned. The folder associated with the root object and the parts related to this folder are retrieved from the database. The type of organization part that performs this function is determined as indicated below. The identifier of the transaction manager company associated with this transaction is obtained. The objects in the part of the folder are scanned and the part object is located with the same company identifier. If the company does not exist as a part of this folder, then a FAIL is returned. Gets the part type of the part object. If the part type for this function does not correspond to this type of organization part for commercial transactions (ie, folders) then a FAULT is returned. This check ensures that the organization that performs this function operates within the relationships defined for this specific business transaction. For editing functions, the Checkworkflow () administrator workflow verification method268Workflow is invoked to determine if this function is valid or not based on the current state of the flow of the folder. If the function is not valid, an error is returned. After completing the previous validations the method of preparing the transaction object is invoked. A sample implementation of this method is provided in the SCTran class (which only returns). The purpose of this method is to pass control to the application-specific version of this method in the transaction class of the application. If this method is implemented, perform any specific initialization of the application as necessary. Upon returning from the preparation method, an output OG is created using the OGS and the commercial objects within the editing context. The state of the transaction is set to "preparation", the return code and any other output parameters are established and returned to the subsystem that makes the invocation. For the functions of insertion the following operations are carried out. If the state of the transaction is "prepare" (that is, a "preparation" has already been performed), the transaction is restored to its "Init" state. Based on the root object class, a new business object of this class is created. The checkworkflow () workflow verification method of the workflow manager is invoked to determine if the function is valid or not based on269in the current workflow status of the folder. If the function is not valid, an error is returned. The method of preparation of the object of this transaction is invoked. A sample implementation of this method is provided in the SCTran class (which only returns). The purpose of this method is to pass control to the application-specific version of this method in the transaction class of the application. If this method is implemented, it performs the transaction-specific initialization as required. Upon returning from the preparation method, an output OG is created using the OGS and the commercial objects within the editing context. The state of the transaction is set to "preparation", the return code and any other output parameters are set and returned to the subsystem that made the invocation. Validation processing The following operations are performed during validation processing. If the transaction is in an "Init" state (that is, the preparation has not been reflected), the preparation method _prepare () is invoked (see preparation processing in previous paragraphs.) If the transaction is in a valid state (it is say, a validation has already been performed) commercial objects are re-established within the context of editing again in the state that existed immediately after the270preparation processing. If an input OG is provided, the data elements with indicator as the input elements (within the OGS) will be validated (a syntactic validation). When using the object hierarchy defined within the OGS, the validation method _validate () of each commercial object is invoked by starting at the bottom of the hierarchy and going to the top. This validation sequence provides an orderly validation for all business objects within the transaction. After completing the above validations, the validation method of the transaction object is invoked. A sample implementation of this method is provided in the SCTran class (which merely makes a return). The objective of this method is to pass control to the specific version of the application using this method in the transaction class of the application. If this method is implemented, validations and specific processing of the application are carried out as necessary. NOTE: This method is only invoked after all business objects within the transaction are validated. If errors are detected in the application, commercial objects are re-established within the edit context again in the state they existed immediately after preparation processing and returns an ERROR. After returning from the validation method, the alert generation method271GenerateAlerts () the alert manager is invoked. This method evaluates the business rules for all parties involved in this transaction and generates the appropriate alert objects (SAAIert) within the editing context. After processing the alerts, the workflow evaluation method of the workflow manager is invoked. Based on the function of the application that is processed, this method sets the following workflow status for the folder. After evaluating the workflow, the method to generate an event history (GenerateHistoryEvents ()) of the transaction object is invoked. This method crosses the hierarchy of the business object for this transaction and generates the event objects (SAEvent) based on the changes of the business objects (derived from the SADocument). After generating the historical events, the method to generate a determination message (GenerateCompletionMessage ()) of the objects of the transaction are invoked. When using the determination message template defined in the function, this method generates a specific message for this function and adds it to the message matrix (for this transaction). An output OG is waxed using the OGS for the function and business objects within the editing context. The status of the transaction is established in "validate" the return code and any other output parameter is established, and272returns an invocation subsystem. Assignment processing During assignment processing, the following operations are performed. If the transaction is in an "Init" state (ie we have made a preparation), the preparation method (_prepare () see the previous preparation processing) is invoked. If the transaction is in a "ready" state (ie a validation has not been performed), a validation method is invoked (_validate () see the previous validation processing). The lock check method SAAttachment of the lock manager for this folder is invoked. If it is not satisfactory, it returns an ERROR. Otherwise, this method regenerates the blocking (in this way it ensures that nobody else modifies the folder). Within the context of editing this transaction object, all commercial objects (which have already been modified) are assigned to the database. The folder is unlocked. Logical processing of the application Based on the structure analyzed above, the logic of the application required for applications built with the A / F is greatly simplified. The application logic is encoded within the 2 main sets of objects, the transaction classes of the application and the classes of the business object. Application transaction classes273The application transaction class supports one or more intrinsic elements within the application. With each class, the following methods are encoded. Preparation method: this method is used to perform a specific initialization of the application for the transaction. Validation method: this method is used to perform validations and specific processing of the transaction application. Business object classes Each transaction consists of one or more business objects. Commercial objects represent the entities of the data for the application system. Within each class, the following method is encoded. Validation method: this method is used to perform the validation in specific processing for the commercial object. Due to an ordered sequence in which this method is invoked, all dependent objects (that is, children) that are related to this object are validated before this method is invoked for this object. In this way, this validation and processing can include any complex validations, cross-edits or manipulations of any dependent objects that are subordinate to this object. Processing system services various subsystems and objects described274formerly based on an enriched set of system services with these services are further described in this section. Blocking and reservation By centralizing the associated data transactions between organizations in a common network / database, the system facilitates the ability of each organization to collaborate with each other. In this way, when a certain organization performs a function with respect to a certain commercial transaction, the system automatically provides the block and the reservation of the folders as indicated below. In general, anyone can access the information for a specific commercial transaction (read-only) at any time (even if the folder is blocked). When an editing function is performed the folder is locked until the editing function is complete. For team ownership, when a folder is returned to an operator of the query, it is blocked until the operator retrieves another folder or exits the system. This allows an operator within the team to perform several functions in the folder without blocking someone else from accessing the folder. When the folder is blocked by an organization, if another organization tries to block it (for275example, performing an editing function), the system notifies the operator that the folder is blocked by the other organization. To prevent a folder from being blocked for an excessive amount of time a timeout mechanism is provided. This mechanism "unlocks" the folder until it issues the time period out. Graphical object services With a multi-part transaction processing, each transaction request needs to be filtered to limit the input and output data elements for the specific part. This multi-part data filtering is done through the TPL using an object graphic specification (OGS). Each transaction request is associated with a function (whose definition is contained within the system configuration). An OGS is associated with each function. The OGS defines the set of data entities and their attributes and the structure of the object, for a given transaction request (that is, a function). Each interface subsystem converts the incoming transaction request into an object graph (that is, a hierarchical structure oriented to the object of key pairs two value points). The interface subsystem then invokes the TPL to process the transaction.276When using the OGS associated with the function for this transaction request, the TPL validates the input data provided with the transaction request. By doing so, it only receives and processes the elements of the input data that are specified in the OGS (in this way it avoids the creation or modification of data elements that are not allowed for this part). After processing the input data, the TPL invokes the logic of the application to process the transaction. Once the application logic has completed the processing, the TPL uses the OGS to prepare a new object graph that contains the results of the application processing. In doing so, the resulting OG only contains the data elements that are defined within the OGS (in this way it only sends the data elements that are allowed for this part). After the TPL completes its processing, its interface system converts the new object graph (back by the TPL) into an outgoing transaction response.
Essentially, the object graphics services ensure that a particular party can only send or receive data elements allowed for its part type. Another unique aspect for this service is its ability to isolate the logic of the application from the filtering details of the part type. This means to a large extent the resulting application code while also supporting a large277number of related transactions that differ with respect to the content of the data. Administering alerts and business rules To handle the unique processing requirements for each member organization, the system supports the definition of business rules that are specific to each organization. These definitions of business rules are defined within the system configuration (and vary with each vertical application). Each time the TPL processes an edit function, it invokes the alert manager to perform an evaluation of business rules and generate an alert. For each part that is defined in the folder (associated with this transaction), the alert manager retrieves and evaluates all business rules that apply. In the evaluation of each commercial rule if the commercial rule fails, an alert is generated. These commercial rules are re-evaluated at any time that a new edition function is made to the folder (anywhere). Within each folder, a collection of alerts is maintained. This collection represents the current set of exceptional business conditions that exist within the folder. When an alert is generated, a definition of alert rules within the system configuration is used to determine what part types should be allowed for278Access this alert. In this way, some alerts can be private for a specific part, while other alerts can be public for several parties. Essentially, the alert management and trade rules services provide the organization with a processing of specific business rules. This service is exclusive since it has multi-part processing capabilities. Workflow management Each time the TPL processes an edit function, it invokes the workflow administrator to determine the next workflow status for the folder (that is, workflow management). For more information on this capability, refer to the related section on "inter-organizational workflow management." Security administration The security management service addresses security requirements within the organization and between organizations. The following summarizes these security management capabilities. The security service always validates the identity of any operator or automated system that tries to connect to the system and perform the transactions (that is, validates the requestor).279Once the identity of the applicant is verified, the following set of security restrictions between organizations is verified. It ensures that an applicant can only access the folders (business transactions) and related folder data, for which their organization is a valid part. It is ensured that the applicant can only perform the functions for which his organization is authorized (based on the valid set of types of parts defined for his organization). For a given folder (commercial transaction), it is assured that an applicant can only perform the functions for which he has permission through the relationship (type of part) of his organization for that folder. For a given folder (business transaction) it is ensured that an applicant can only perform the functions for which his part type has permission based on the current workflow status of that folder. For a given folder (business transaction), it ensures that the requestor can only send / receive data elements that are allowed through the relationship (party type) of their organization for that folder. Within the restrictions established through the security mechanisms within the organizations, the following restrictions are verified within the organization. Ensures that an applicant has only280access to folders (business transactions) that are allowed on your paper. Ensures that an applicant can perform only the functions that are defined on their paper. Ensures that an applicant can only send / receive data elements that are authorized through their paper. Essentially, the security management service ensures and maintains the privacy of the data within the system. It is unique in its ability to handle security restrictions within the organization within the context of security restrictions between organizations. Individual and team property For each system folder, you must specify an owner for each organization (part) that is defined for that folder. This allows the system to identify the specific group or individual responsible for handling the transaction within each organization. The system can support individual or equipment ownership. With individual ownership, the folder is of a specific individual within a given organization. With this property method, the individual operator manages their folders using a variety of forms and filters. The ownership of this folder remains with that individual until it is transferred to another individual or281complete the transaction. With team ownership, the folder is owned by a group of operators (not an individual operator). This property method is typically used in large organizations with high transaction volumes (for example, insurance claims, handling purchase requests, etc.) and provides greater efficiency in file management and improved correspondence. When using this method, a group of operators are assigned to process a query of folders that share a common set of characteristics (for example, a status of the workflow, geography, quantity, business condition, etc.). The following additional services are provided to give full support to the equipment property. One or more "get job" functions can be defined that allow group operators to retrieve a folder from the folders query. The selection criteria that define the folders that belong to a certain query can be simple or extremely complex. The blocking and special reservation of the handling is provided (for more information, see the section "blocking and reservation"). External notifications In addition to the electronic message capabilities provided by the message translation service, the282The system also supports the ability to use external communication services for the purpose of issuing notifications. This capability is referred to as the external notification service. This service is useful for sending notifications to people who are infrequent users of the system. This allows users to have notification about the commercial activity that occurs within the system (without having an entry to the system and verify the system on a regular basis). For events that are processed through the event manager, if an external notification is defined for that event, the event manager invokes the external notification administrator to generate the notification. Examples of external communication networks typically used for external notifications include email, fax, pager, cell phone, PDA, and other wireless devices. Instant services For each folder, the event manager subsystem maintains a rich business history on all folder modifications. Within each event, a complete collection of the business object hierarchy is preserved for the transaction. The mechanism283Instant is designed to avoid overload by keeping historical data within each application table different in the database. Essentially, the snapshot is a data globule (in XML format) that contains the hierarchy of the business object that existed within a transaction when the transaction was assigned to the database. When creating an event within a transaction, the method to create an event (CreateEvent ()) uses the root object for the event and generates a snapshot image object (SASnapshot) for this event using the OGS of the snapshot image that is define in the event template associated with this event. A reference to this object is stored in the created event object. These objects are written to the database, along with all the other data for the transaction during the "assign" processing. To visualize business objects within an instant image, the snapshot object is first retrieved from the database. Then a special editing context is created. Finally, the data globule of the instantaneous image (XML flow) is analyzed and each individual business object is reconstituted within the context of special edition. The TPL then prepares an output GO using the commercial objects contained in this editing context.284Reporting With any given application, the transactions of several organizations are contained within a database. To protect the privacy of each of the organization, no organization can have a direct link to the database to notify the objectives. The reporting service was designed to provide a facility for producing high-performance reports to generate reports. Essentially, the reporting service uses the same mechanisms that use the visualization functions within the system. However, instead of retrieving objects from the database, this service uses "raw" query mechanism and aggregates (for example, raw SQL) to allow the database to summarize and aggregate data in the databases. data. This greatly reduces the amount of data transferred between the database server and the application server. These raw rows will move to the Jview ™ environment within the search engine for presentation. Document management Although many of the facilities within the system are oriented around the administration of structured documents, an enriched set of document management services is provided285to manage unstructured documents. Essentially, an unstructured document is treated as a binary globule and can support virtually any type of document (for example, word processing documents, spreadsheets, graphics, images / photos, animations, audio, video, etc.). The document management service provides a variety of methods for importing these documents into the system. These mechanisms include HTTP, FTP, email and URL extraction. When a new unstructured document is appended to a folder, an attachment object (SAAttachment) is created. This object contains metadata related to the document. In addition, the actual document itself is stored within an object of the appended data (SAAttachmentData). Within this object, the binary data representing the document is stored in a bead. In fact, based on the primary type of the annexed document, two globules are actually stored within the annexed data object, a native globule and a generic globule. The native globule contains the actual binary data in the original document. The generic globule contains a version of the original document converted into a common format (for example, PDF for P3 documents for audio, MPEG for video, etc.).286When a new revision of a particular annex is received, a new annexed data object is created. The object of the annex keeps a list of all the revisions of a given document (in this way it provides a complete revision history for the document). Within each annexed object, the current part grid attribute (currentPartyArray) is used to define the parts within the folder that can access the annex. Illustrative embodiments of the present invention have been described. However, a person skilled in the art may note that some modifications are evident within the teachings of the present invention.