Automatic discovery of processes executed

Abstract

Data is collected from log files on the first application server, log files on the second application server, databases on the database server, or any suitable combination thereof. By correlating data from different sources, XP-Functions that are executed in sequence on a single application server are identified and combined into sequences called executable process chains (XP-Chains). The automatic process discovery server reconstructs end-to-end processes from the XP-Chains based on the log file and database data, even when the XP-Chains are executed on different application servers. Test scripts can be generated for the identified end-to-end processes. By running the test scripts, the proper functioning of the end-to-end processes can be confirmed. For previously identified end-to-end processes that are discovered to no longer be executed, existing test scripts can be disabled.

Description

Technical Field

[0001] The subject matter disclosed herein generally relates to the discovery of executed processes. Specifically, this disclosure relates to systems and methods for automatically identifying executed processes, including their tasks, and the system objects in which they are executed. Background Technology

[0002] Using current technology, experts manually describe, map, and sort process objects and end-to-end processes. Analytical tools analyze database logs to determine partial sequences of operations on objects, but cannot fully define end-to-end processes that include system steps and their tasks not reflected in the database logs. Attached Figure Description

[0003] Some embodiments are shown in the accompanying drawings by way of example rather than limitation.

[0004] Figure 1 This is a network diagram illustrating a network environment suitable for the automatic discovery process, based on some example embodiments.

[0005] Figure 2 This is a block diagram of a process discovery server suitable for automatic discovery execution according to some example embodiments.

[0006] Figures 3-9 This is a block diagram of a database schema suitable for use by a process discovery server during autodiscovery execution, based on some example embodiments.

[0007] Figure 10 This is a schematic diagram of a UI suitable for the execution process of automatic discovery, based on some example embodiments.

[0008] Figure 11 This is a schematic diagram of a UI suitable for the execution process of automatic discovery, based on some example embodiments.

[0009] Figure 12 This is a schematic diagram of a UI suitable for the execution process of automatic discovery, based on some example embodiments.

[0010] Figure 13 This is a schematic diagram of a UI for navigating among process areas, processes, functions, transactions, programs, interfaces, batch jobs, and roles, based on some example embodiments.

[0011] Figure 14 These are schematic diagrams of a UI used to display functions during execution, based on some example embodiments.

[0012] Figure 15 These are schematic diagrams of a UI used to display functions during execution, based on some example embodiments.

[0013] Figure 16 This is a schematic diagram of a UI used to display the process of discovery execution, based on some example embodiments.

[0014] Figure 17 This is a schematic diagram of a UI for displaying a chain of functions discovered during the execution process, based on some example embodiments.

[0015] Figure 18 This is a flowchart illustrating operations suitable for automatically discovering and executing processes and generating test scripts for the discovery process, based on some example embodiments.

[0016] Figure 19 This is a block diagram illustrating an example of a software architecture used in computing devices.

[0017] Figure 20 It is a block diagram of a machine in the form of an example computer system, within which instructions can be executed to cause the machine to perform any or more of the methodologies discussed herein. Detailed Implementation

[0018] The example methods and system pointers point to the automatically discovered execution processes. These processes generate log files on the systems in which they execute. These log files can be used for system debugging, usage and performance monitoring, or both. Information in the logs can be used to identify the executed processes. Some information in the logs is also stored in database tables, but some information, especially information related to executable system objects, is available in the logs but not in the database tables.

[0019] As described herein, data is collected from log files on a first application server, log files on a second application server, a database on a database server, or any suitable combination thereof. Executable process units (XP-Cells) are identified by associating data from different sources. An XP-Cell is a unique combination of objects manipulated by an executing process on the system. In some example embodiments, each XP-Cell is assigned an index name defined by the component object, parameters, object category, and relationship to other XP-Cells. In various example embodiments, XP-Cells include interactive user sessions, automated interactions, background jobs, or any suitable combination thereof.

[0020] Each XP-Cell has a corresponding executable process function (XP-Function). Each XP-Function can be assigned a name describing its purpose (e.g., a name including the raw text and target code of the server being analyzed, the raw text and target code of the database accessed by the server being analyzed, or any suitable combination thereof). XP-Functions executed sequentially on a single application server are grouped into a sequence called an executable process chain (XP-Chain). Each XP-Function can be categorized as a dialog XP-Function executed via direct user interaction with the system, an interface XP-Function executed via an indirect user interface, a batch XP-Function executed via a background job, or any suitable combination thereof. Furthermore, each XP-Function can be labeled as an active XP-Function with associated document logs or a reporting XP-Function without document logs. Reporting XP-Functions can be used to list and report data in the system. Interface XP-Functions can be used to join end-to-end processes across systems, showing where a process begins, where it ends, and how it interacts with other processes from different systems. The sample documents include sales orders, delivery documents, and invoicing documents.

[0021] Interface XP-Functions can be further classified into receive / transmit XP-Functions and pure interface XP-Functions. Receive / transmit XP-Functions communicate data between or within application servers. Pure interface XP-Functions execute functions in the receiving application server based on interface messages (instructions) from another application server.

[0022] Batch jobs are scheduled background processes that run periodically without any user intervention. Batch jobs can be used to process large amounts of data and execute procedures that do not require user interaction. For example, once all the order fields in a sales order have been completed, a batch job can be scheduled to create the delivery documentation for that sales order.

[0023] Reporting XP-Functions are executed by system transactions and programs to read data from the database and generate output based on filters selected by the end user. Reports can be standard reports, custom reports, or ad-hoc queries. The name of a reporting XP-Function may include the name of the program providing the XP-Function, the role used to execute the XP-Function, the associated authorized object, the table name used to collect data for the report, the functional module, a timestamp, or any suitable combination thereof. Because many reporting XP-Functions access data without modifying it, many existing process discovery systems cannot detect reporting XP-Functions. However, the reports generated by reporting XP-Functions are often critical to the users of the system. Accurately detecting reporting XP-Functions improves application testing and migration.

[0024] The automated process discovery server reconstructs end-to-end processes from XP-Chain based on log files and XP-Cells, even when XP-Chain is executed on different application servers. Data about the end-to-end processes is stored in a process repository that links objects to processes. Log files and the database can be monitored periodically without interrupting the application served by the application server, and the end-to-end process data can be updated.

[0025] XP-Function includes one or more operations for creating, modifying, or deleting business objects. A business object is an object (in the sense of object-oriented programming) or data structure that represents a business entity. A business entity is any person, place, thing, document, or service related to a business. Example business entities include users (e.g., employees), customers, companies, sales orders, invoices, products, and services. Business objects have a lifecycle in which they are created, used, and destroyed. For example, an employee's business object is created when the employee is hired, maintained and modified during the employee's employment period, and can be deleted or archived when the relationship with the employee is terminated. Business processes can be associated with a portion (or all) of the lifecycle of a business object. For example, an individual sales order can be created, modified, and deleted, and XP-Function reflects and visualizes these operations on that individual sales order. The methods and systems described herein operate on business processes and business objects, but the subject matter of the invention is not limited thereto.

[0026] Each time an application executes an XP-Function, it identifies the type of business object being processed to identify the business process. For example, if a user is processing a specific invoice with the identifier 12314, the log or database entry generated by the application will include the identifier 12314 as a numeric or string value. Therefore, each log file and database entry can be analyzed to determine if it involves the identified invoice and the corresponding identified business object. The identifier can include both string and numeric parts, such as "invoice 12314". For example, if a user is processing a specific customer with the identifier 54321, the log file or database will contain the string "customer 54321". Thus, the automated process discovery system can determine whether the business object being processed is a customer or an invoice, and the specific business object being processed.

[0027] Test scripts can be generated for identified end-to-end processes. For example, by identifying instances of the end-to-end process from the first XP-Function to the last, successful instances of the end-to-end process can be reconstructed from logs and the database. Data used in the successful instances can be collected as test cases. Repetition of successful instances can also be expected as successful instances when running on a test server, a test database, or both. Therefore, test scripts that repeat successful instances can be created. By running the test scripts at later times, the proper functioning of the end-to-end process can be confirmed. For example, the test scripts could run daily, after a software upgrade deployment, or both.

[0028] For previously identified end-to-end processes that are no longer being executed, existing test scripts can be disabled. For example, a discovered process can be stored in a process repository along with a datestamp indicating the last time the process was observed. During testing, test scripts can be run only for processes observed within a specific timeframe (e.g., one week, one month, or one year prior to the test).

[0029] Furthermore, the discovered end-to-end processes, along with their components XP-Chain and XP-Function, can be used to guide process archiving. By identifying which end-to-end processes are actually in use on existing platforms and verifying that those processes are correctly implemented and tested on new platforms, application migration from one implementation to another (e.g., from a first platform using a traditional database that relies on disk storage to a second platform using an in-memory database implementation) can be accomplished, and errors reduced. Similarly, by focusing testing on processes that are actually in use on the new platform, the effort spent on testing can be reduced.

[0030] By comparing with existing methods of process discovery, the methods and systems discussed in this paper reduce the level of effort required in the discovery process and improve its accuracy. Existing methods of process discovery are manually driven and therefore cannot practically monitor every XP-Function, leading to missed XP-Functions, XP-Chains, and end-to-end processes. Furthermore, because manually driven processes rely on human judgment rather than rigorous data evaluation, assumptions about which processes are executed can lead to the testing and maintenance of XP-Chains and end-to-end processes that are not actually used.

[0031] By comparing with other automated methods for discovery processes, the methods and systems discussed in this paper are able to identify end-to-end processes that cannot be detected using existing methods. For example, front-end process mining detects user interactions with an application but cannot detect fully automated process steps. As another example, tools that collect process data from log files on a single server detect process steps recorded in logs on that single server but cannot detect process steps executed on other servers. Tools that collect process data from log files on a database server only detect process steps recorded in logs but cannot detect background processing logs of executable objects and automated steps deployed on application servers and not stored in database log files.

[0032] When these effects are taken into account, one or more of the methods described herein can eliminate the need for certain effort or resources that would otherwise be involved in process discovery and testing. Computational resources used by one or more machines, databases, or networks can be similarly reduced. Examples of such computational resources include processor cycles, network traffic, memory usage, data storage capacity, power consumption, and cooling capacity.

[0033] Figure 1 This is a network diagram illustrating a network environment 100 suitable for automatically discovering and executing processes, according to some example embodiments. Network environment 100 includes a network-based application 110, client devices 160A and 160B, a test device 170, and a network 190. The network-based application 110 is provided by application servers 120A-120B that communicate with corresponding database servers 130A (which stores application data 135A and process discovery data 140A) and 130B (which stores application data 135B and process discovery data 140B). The processes provided by application servers 120A-120B are monitored by a process discovery server 150, which also communicates with database servers 130A-130B. A process discovery component 125A or 125B runs on each of the application servers 120A-120B. Process discovery components 125A-125B communicate with process discovery server 150.

[0034] Application servers 120A-120B access application data 135A-135B to provide one or more applications to client devices 160A and 160B via Web interface 180 or application interface 175. Each of the application servers 120A-120B, process discovery server 150, database servers 130A-130B, test device 170, and client devices 160A and 160B can be implemented wholly or partially within the computer system, as described below. Figure 17 As described, client devices 160A and 160B can be collectively referred to as client devices 160 or generally as client devices 160.

[0035] Process discovery server 150 receives data about interactions with applications from one or more application servers 120A-120B, one or more database servers 130A-130B, or any suitable combination thereof. Process discovery components 125A-125B, installed on each of the application servers 120A-120B, analyze database and application server log files and automatically discover executed processes. Data about the discovered processes can be created and stored in process discovery data 140A-140B, provided to process discovery server 150 for aggregation in process discovery storage 155, or any suitable combination thereof. Process discovery server 150 is used to periodically extract and aggregate discovered processes from process discovery data 140A-140B. The process server sorts the processes, combines object IDs with text, and creates end-to-end processes from the received process steps and associated data elements. The process server 150 has its own process discovery storage 155, which is used to generate test scripts for processes to generate user interfaces that display information about XP-Function, XP-Chain, and end-to-end processes or any suitable combination thereof.

[0036] Figure 1 Any of the machines, databases, or devices shown can be implemented in a general-purpose computer that has been modified (e.g., configured or programmed) into a special-purpose computer to perform the functions described herein for that machine, database, or device. For example, the following regarding Figure 17 Computer systems capable of implementing any one or more of the methodologies described herein are discussed. As used herein, a "database" is a data storage resource and can store data structured as text files, tables, spreadsheets, relational databases (e.g., object-relational databases), triplet stores, hierarchical data stores, document-oriented NoSQL databases, file stores, or any suitable combination thereof. Databases can be in-memory databases. Furthermore, Figure 1Any two or more of the machines, databases or devices shown may be combined in a single machine, database or device, and the functionality described herein for any single machine, database or device may be subdivided among multiple machines, databases or devices.

[0037] Application servers 120A-120B, process discovery server 150, database servers 130A-130B, test equipment 170, and client devices 160A-160B are connected by network 190. Network 190 can be any network that enables communication between or within the machines, databases, and devices. Therefore, network 190 can be a wired network, a wireless network (e.g., a mobile network or a cellular network), or any suitable combination thereof. Network 190 may include one or more parts constituting a private network, a public network (e.g., the Internet), or any suitable combination thereof.

[0038] Test device 170 interacts with the network-based application 110 just like client device 160, but runs test scripts instead of providing client interaction. For example, before deploying an updated version of the application software, test device 170 can run a set of test scripts against the updated version. If all test scripts execute successfully, software deployment continues. Otherwise, errors are notified to the administrator or developers, allowing the release candidate software to be updated before deployment.

[0039] In some example embodiments, process discovery server 150 is configured to periodically (e.g., daily) or in response to user commands (e.g., user commands received from client device 160A via web interface 180) request data from application servers 120A-120B and database servers 130A-130B. Although Figure 1 Two application servers 120A-120B and two single database servers 130A-130B are shown, but more application servers, more database servers, or both are used in various example embodiments. For example, three application servers and two database servers may be used.

[0040] For each system database analyzed by process discovery server 150, process discovery components 125A-125B create process discovery data 140A-140B. In this way, sensitive business data of application servers 120A-120B is not imported into a separate database of process discovery server 150. Instead, process discovery server 150 analyzes sensitive business data within the application system itself (e.g., data of application server 120B stored within application server 120B and its database server 130B). Relationships between data elements and new data containing process definitions (e.g., in the form of XP-Cell indexes) are stored in process discovery data 140A-140B, process discovery storage device 155, or any suitable combination thereof. Process discovery data may also include system configuration parameters, executable objects, roles, user types, or any suitable combination thereof.

[0041] Process discovery server 150 collects identified process discovery data from process discovery data 140A-140B and aggregates it into process discovery storage device 155. In some example embodiments, the aggregated data contains only data fields relevant to process execution, rather than all data fields containing sensitive business information (such as price, user ID, order quantity, etc.). Alternatively, sensitive business information can be included in process discovery storage device 155 as needed and in accordance with strictly approved business requirements.

[0042] Figure 2 This is a block diagram 200 of a process discovery server 150 suitable for automated discovery execution, according to some example embodiments. The process discovery server 150 is shown as including a communication module 210, a UI module 220, a process discovery module 230, a test creation module 240, a storage module 250, and an analysis and reporting module 260, all configured to communicate with each other (e.g., via a bus, shared memory, or switch). Any one or more of the modules described herein can be implemented using hardware (e.g., a machine's processor). For example, any module described herein can be implemented by a processor configured to perform the operations described herein for that module. Furthermore, any two or more of these modules can be combined into a single module, and the functionality described herein for a single module can be subdivided among multiple modules. Additionally, modules described herein as being implemented within a single machine, database, or device, according to various example embodiments, can be distributed across multiple machines, databases, or devices.

[0043] Communication module 210 receives data sent to and from process discovery server 150. For example, communication module 210 may receive log data indicating the functions performed on an object from application servers 120A-120B. Communication module 210 provides this data to process discovery module 230, which stores the discovered process data in the database of database server 130, or any suitable combination thereof, via storage module 250. The communication sent and received by communication module 210 may be facilitated by network 190.

[0044] The process discovery module 230 receives reconstructed process data from process discovery components 125A-125B from application servers 120A-120B and process discovery data 140A-140B from database servers 130A-130B. For example, the process discovery module 230 may request process data, the application servers 120A-120B may push log data, or both. In some example embodiments, process data is received via communication module 210. The discovered process data and intermediate results may be stored in a database via storage module 250. The process discovery module 230 evaluates the process data to identify the XP-Function text name, XP-Chain, and end-to-end process. After the data is stored, it can be accessed from database servers 130A-130B, storage module 250, or both, depending on how the aggregation was established.

[0045] For example, multiple users on different client devices 160 interact with different UIs provided by different application servers 120A-120B while processing a single business process (e.g., a standard sales order process). Data collected during each interaction is stored by the corresponding application server 120A-120B as log data on application server 120A or 120B, or as application data 135A or 135B on database server 130A or 130B. The collected data is analyzed by process discovery component 125A or 125B, and the process data is identified as XP-Cells and their relationships. The process data is stored in process discovery data 140A or 140B, process discovery storage device 155, or any suitable combination thereof, and sent to process discovery module 230 to reconstruct the process and end-to-end process.

[0046] Test creation module 240 generates test scripts to test discovered individual process chains or end-to-end processes. Test scripts can be automatically created based on discovered process chains or end-to-end processes that are known to have executed successfully, and they run automatically whenever changes are made to application servers 120A-120B. If a process chain or end-to-end process is not executed within a predetermined time period (e.g., a period determined by an administrator or otherwise, such as a week, month, or year), the test script can be removed from the set of automatically running scripts.

[0047] UI module 220 enables the UI of process discovery server 150 to be displayed on a monitor (e.g., a monitor associated with the administrator of the process, or a monitor on the device of another user interested in understanding and optimizing the process). The UI allows users to select processes from a list of processes, view process data for the selected process, modify processes, select processes or process tasks for use in the automatic discovery generation of test scripts based on that process or task, or any suitable combination thereof.

[0048] The Analysis and Reporting Module 260 uses existing methods to provide various graphs, charts, alerts, Key Performance Indicator (KPI) dashboards, and reports to analyze how business units use processes and steps, critical process paths, key business object types and system configurations, executable usage, execution patterns, alerts about execution inconsistencies (e.g., use of incorrect or unexpected system transactions or procedures, execution of the same end-to-end process in different ways, or both), and analysis diagrams showing which critical processes and executables must be included in the test plan and covered in end-to-end testing. The Analysis and Reporting Module 260 can also be used to show gaps or similarities in how the same process is executed in separate systems. For example, if two systems are planned to be merged, such as application servers 120A and 120B being merged into a single application server, reports from the Analysis and Reporting Module 260 can help understand how the processes for merging these systems can be achieved.

[0049] Process discovery module 230 uses process discovery data to analyze the consistency of configured roles, document type usage and consistency, relative importance of document types (e.g., if CBM0 handles 100,000 projects while ZCB0 handles 10 projects, then CBM0 is a higher priority document type), usage of standard and custom transactions, the number of transactions running most / least of processes, simultaneous execution of the same / same XP-Function by automated batch jobs and dialogs, process consistency of the same end-to-end scenarios configured differently in the system (duplicated configurations mean duplicate system ownership costs), and key end-to-end scenarios in the test scope (e.g., if 30 out of 200 scenarios run 90% of the business, then those 30 scenarios should be handled with higher priority). Additional reports generated by analysis and reporting module 260 include: the number of transactions deployed in a process, the number of times an XP-Function is triggered, a list of all transactions to be tested for each process chain or process set, or any suitable combination thereof. The generated reports or analyses may also show discrepancies or similarities in how the same process is executed in separate systems. For example, showing the reports produced in the two systems can help administrators understand the process of merging these systems.

[0050] Figures 3-9 This is a block diagram of a database schema 300 suitable for use by a process discovery server during auto-discovery execution, according to some example embodiments. Process discovery components 125A-125B can use database schema 300 to store and access process discovery data 140A-140B of database servers 130A-130B. Database schema 300 includes a process discovery table 310, a process type table 410, a user type table 440, a business object table 470, an XP-Function table 510, an XP-Chain table 610, a process set table 640, an object category table 710, an executable object table 740, an executed object table 810, a single role table 840 for process types, a single role table 910 for executable objects, and a composite role table 940.

[0051] In some example embodiments, process discovery data 140A-140B includes XP-Cell data but excludes tables of XP-Functions or XP-Chains stored in process discovery storage 155. UI-specific data views can be created from process discovery data 140A-140B by process discovery server 150 using remote data services such as Advanced Business Application Programming (ABAP) Core Data Services. For performance reasons, a portion of process discovery data 140A-140B can be copied to process discovery storage 155, thereby reducing network bandwidth consumed during UI generation.

[0052] The process discovery table 310 includes rows 330A, 330B, 330C, 330D, 330E, and 330F of format 320. The process type table 410 includes rows 430A, 430B, 430C, 430D, 430E, and 430F of format 420. The user type table 440 includes rows 460A and 460B of format 450. The business object table 470 includes rows 490A, 490B, and 490C of format 480. The XP-Function table 510 includes rows 530A, 530B, 530C, 530D, 530E, and 530F of format 520. The XP-Chain table 610 includes rows 630A and 630B of format 620. The process set table 640 includes rows 660A, 660B, 660C, 660D, 660E, 660F, and 660G in format 650. The object category table 710 includes rows 730A, 730B, 730C, 730D, 730E, 730F, 730G, and 730H in format 720. The executable object table 740 includes rows 760A, 760B, 760C, and 760D in format 750. The executed object table 810 includes rows 830A, 830B, 830C, 830D, 830E, 830F, 830G, and 830H in format 820. The single role table 840 for process types includes rows 860A, 860B, 860C, and 860D in format 850. The single role table 910 for executable objects includes rows 930A, 930B, 930C, and 930D ​​of format 920. The composite role table 940 includes rows 960A, 960B, 960C, and 960D of format 950.

[0053] The format 320 of the process discovery table 310 includes an object identifier field, a system identifier field, a client identifier field, an object category identifier field, a process type identifier field, a project type field, a user type field, an organization type field, a key executable object field, and an XP-Cell index field. Each row in rows 330A-330F stores process discovery data for a single event (e.g., order update data). An event may contain multiple field changes (e.g., changes to the order's value, due date, and address). The XP-Cell index field identifies the XP-Cell, and its index name is further used to identify the XP-Function used to generate the event. For example, the function identifier may identify a UI that receives user interaction through it, a script that receives automated interaction through it, or any suitable combination thereof.

[0054] The object identifier identifies the business object to which the event was applied. For example, in an invoice generation UI, the same item type might be used for multiple invoices, but each invoice would have a different object identifier. The object category identifier field identifies the category of the identified object. The client identifier identifies the client device 160 that generated the event (e.g., using an IP address or other identifier). The system identifier identifies the application server 120 that executes the critical executable object. The process type identifier can be cross-referenced with the process type table 410 to identify the process type of the event.

[0055] The user type identifier can be cross-referenced with user type table 440 to determine whether the event was executed by an interactive user session (dialogue, as shown in line 460A) or by an automated process (system, as shown in line 460B). The organization type indicates the type of entity executing the process (e.g., customer, application provider, cloud service provider hosting the application, or any suitable combination thereof). The critical executable object identifies the executed code that generated the event. The critical executable object can be a standalone application, a dynamically linked library, or any suitable combination thereof.

[0056] In some example embodiments, the user identifier of an event is not stored anywhere in the process discovery module 230, storage module 250, or process discovery table 310, thereby allowing the tracking of roles associated with the event rather than specific users to protect user privacy. Figure 1 As shown, user identification data can be stored on database servers 130A-130B and processed by process discovery components 125A-125B, so that process discovery server 150 only accesses anonymous data.

[0057] The format 420 of the process type table 410 includes an object category field, a process type field, and a process type identifier field. Therefore, the type of business process being executed is determined by the category and process type identifier of the manipulated business object. As indicated by line 430A, the process type of an order object with a process type identifier of CBM0 is a Make-to-Order (MTO) standard order. In line 430B, objects of different categories (contracts) but with the same process type identifier (CBM0) have a service contract process type.

[0058] The format 480 of the business object table 470 includes an object identifier field and an object type field. Therefore, the object type of a business object can be determined by looking up the object identifier in the business object table 470. By referring to rows 490A-490C and rows 330A-330D of the business object table 470, the business object is a sales object, the business object in row 330E is a purchasing object, and the business object in row 330F is a customer object.

[0059] Rows 530A-530F of XP-Function table 510 use format 520, which includes a function identifier, an XP-Cell index, and a function description. Therefore, the function description of an XP-Function can be determined by looking up the function identifier in XP-Function table 510. Referring to rows 530A-530D of XP-Function table 510, the business processes for the sales objects in rows 330A-330D include events such as creating different types of orders, changing returns, and creating contracts. Referring to row 530E, the business processes for the purchasing objects in row 330E include batch creation of purchase orders. Referring to row 530F, the business processes for the customer objects in row 530F include creating customer master files using dialogs.

[0060] Rows 630A and 630B of XP-Chain table 610 use format 620, which includes a server identifier, chain identifier, function identifier, and sequence number. An XP-Chain contains one or more functions that execute on a single server. Therefore, rows 630A-630B illustrate XP-Chain chain001 running on server "A" (e.g., application server 120A). XP-Chain chain001 includes XP-Function func001 and func002, which are executed sequentially.

[0061] The format 650 of the process set table 640 includes a process set identifier field, a process set field, and a chain identifier field. Each process executes within one and only one functional business line. This is why each process groups XP-Chains into a chain group consisting of one or more XP-Chains executed within the same functional business line. XP-Chains are stored as a list within the process, not ordered within the process. If multiple XP-Chains are executed sequentially within the same business line, the process can include the sequentially executed XP-Chains. XP-Chains within a process are not always connected to each other, but can be connected to XP-Chains of other processes.

[0062] For example, XP-Chains representing service sales orders, sales contracts, and credit notes are typically not directly connected. The XP-Chain for a service sales order will connect to the XP-Chain for service-related invoicing, which in turn belongs to a different process called invoicing and may even execute on different servers. This is why connections between XP-Chains are not defined and shown within processes, but rather in end-to-end processes, which demonstrate the complete connections between XP-Chains across multiple processes and application servers. Any XP-Chain can be the first, middle, or last XP-Chain in a process. Any connection between XP-Chains is defined herein as an end-to-end scenario. This scenario can begin and end within a process on an application server, connecting and ordering one or more XP-Chains, or it can begin within a process on an application server and continue within other processes on the same or different application servers. The sequence of XP-Chains is not identified within a process. Each XP-Chain can belong to one or more end-to-end scenarios. The XP-Chain sequence is identified in the end-to-end scenario, and the exact location of the XP-Chain in the scenario is determined using the document stream from application server 120A or 120B.

[0063] Table 710 associates business object types with object categories. Therefore, lines 730A-730C show that sales business objects can be orders, contracts, or returns. Lines 730D-730E show that purchasing business objects can be purchase requisitions or purchase orders. Lines 730F-730G show that customer business objects can be customer master files or customer information records.

[0064] Executable object table 740 associates executable objects with their names. Therefore, rows 760A-760D show four distinct executable objects with the name "Create Sales Order". This relationship allows for meaningful, human-readable names while still distinguishing different executable objects performing similar functions. By tracking the executable objects in use, targeted test scripts and automation scripts can be developed.

[0065] The Executed Objects table 810 tracks the execution of executable objects. Each row in lines 830A-830H has a timestamp indicating at which the executable object indicated in that row was executed. Additionally, the Task Type field indicates the type of task performed by the executable object.

[0066] A single role table 840 for process types associates role identifiers and user identifiers with the process type. A single role table 910 for executable objects associates role identifiers and user identifiers with the executable object type. Therefore, each role in a single role table can be used to determine the role of a user accessing a process or executable object, allowing the discovery process component 125A or 125B to anonymize records by replacing user identifiers with role identifiers. Additionally or alternatively, the discovered role identifiers associated with a process can be used to help administrators assign roles to new users who need to perform specific business processes.

[0067] Composite Role Table 940 maps a single composite role identifier for a user identifier to multiple single role identifiers. As can be seen in rows 960A and 960C, multiple user identifiers can be mapped to a single role identifier (e.g., a process role identifier). These user identifiers can still have different role identifiers for other types (e.g., an executable role identifier).

[0068] In addition to the data generated by the process discovery component in pattern 300, the process discovery module 230 can generate data for the tables of pattern 300 by processing log files, database tables, or both. The process discovery module 230 of the process discovery server 150, the process discovery components 125A-125B of the application servers 120A-120B, or any suitable combination thereof analyze any type of processing log files, database tables, or both, regardless of the file's location on the application servers 120A-120B or the database servers 130A-130B. Analyzing a combination of database server logs and application server logs provides comprehensive visibility into how the process is executed. In some example embodiments, the tables of pattern 300 are temporarily stored on the database servers 130A-130B. The process discovery module 230 aggregates the tables of pattern 300 in the storage module 250 for storage on the process discovery server 150.

[0069] Figure 10This is a schematic diagram of a UI 1000 suitable for an automated discovery process according to some example embodiments. UI 1000 includes a header 1010; fields 1020, 1030, and 1040; text 1050; a button 1060; and an information area 1070. Header 1010 indicates that UI 1000 is used to manage sales orders. Fields 1020-1040 are operable to receive search terms for filtering sales order data presented in information area 1070. Text 1050 indicates that information area 1070 contains sales order data and provides the number of sales orders included in information area 1070. Button 1060 is operable to create a sales order. Information area 1070, in response to search terms, provides a sales order identifier, the name of the recipient, the required delivery date, and the value of each sales order. Search terms include plain text search (in field 1020), sales order identifier search (in field 1030), and recipient search (in field 1040).

[0070] Figure 11 This is a schematic diagram of UI 1100 in an execution process suitable for automatic discovery according to some example embodiments. UI 1100 includes a header 1105; indicators 1110, 1130, 1145, 1160, 1175, and 1185; fields 1115, 1135, 1150, 1165, 1180, and 1190; descriptors 1120, 1140, 1155, and 1170; a data area 1125; and a button 1195. The header 1105 indicates that UI 1100 is used to create a sales document. Therefore, UI 1100 can be displayed in response to an operation of button 1060 of UI 1000. Button 1195 is operable to reference an existing quote to complete the sales document.

[0071] Indicator 1110 indicates that field 1115 defines the order type of the sales document. Descriptor 1120 provides a description of the order type indicated in field 1115. Fields 1115, 1135, 1150, 1165, 1180, and 1190 can be implemented as text fields, drop-down lists, combo boxes, or any suitable combination thereof.

[0072] Data area 1125 contains the order's indicator, descriptor, and fields. The sales organization type (indicator 1130) is 1710 (field 1135), indicating a domestic sales organization in the United States (descriptor 1140). The distribution channel type (indicator 1145) is 10 (field 1150), indicating a direct sales channel (descriptor 1155). The department selling the items (indicator 1160) is 00 (field 1165), referring to product department 00 (descriptor 1170). The sales office (indicator 1175) and sales group (indicator 1185) are not yet filled in (fields 1180 and 1190), and therefore have no corresponding descriptors.

[0073] Figure 12 This is a schematic diagram of UI 1200 in an execution process suitable for automatic discovery, according to some example embodiments. UI 1200 includes a header 1205; indicators 1210, 1230, 1245, 1260, 1275, and 1285; fields 1215, 1225, 1235, 1240, 1250, 1265, 1280, and 1290; and descriptors 1220, 1255, and 1270. Header 1205 indicates that UI 1200 is used to create a standard order. UI 1200 may be displayed in response to the operation of button 1195 of UI 1100.

[0074] Indicator 1210 indicates that field 1215 defines the quote on which the sales order is based. The data shown in fields 1225, 1235, 1240, 1250, 1265, 1280, and 1290 is populated by application server 120A based on the quote identified in field 1215. Fields 1225, 1235, 1240, 1250, 1265, 1280, and 1290 can also receive user input to modify the quote data from the sales order.

[0075] As shown in example UI 1200, the order type (field 1225) is a standard order (descriptor 1220); the net value of the order (indicator 1230) is $353.50 (fields 1235 and 1240); the recipient (indicator 1245) has identifier 1810005 (field 1250) and is a domestic customer located on Second Avenue, Billings, Montana (indicator 1255); the recipient (indicator 1260) is the same as the recipient (field 1265) and has the same description (descriptor 1270); the customer reference identifier (indicator 1275) is CR1809011 (field 1280); and the requested delivery date (indicator 1285) is December 21, 2018 (field 1290).

[0076] UIs 1000-UI 1200 can be generated by one or more of application servers 120A-120B. User interaction with UIs 1000-UI 1200 can result in log entries being added to log files stored on application servers 120A-120B. Each log entry identifies a document taken as input by an XP-Function, a document provided as output by an XP-Function, or both. For example, in response to an action on button 1050 labeled "Create Sales Order," the log entry associated with UI 1000 may include an identifier for the newly created sales order document. Log entries associated with UI 1100 may also include an identifier for the sales order document and record changes made by the user. Log entries for UIs 1000 and 1100 can reside in separate log files on different application servers within application servers 120A-120B. Therefore, by accessing log files on multiple application servers, process discovery components 125A-125B, process discovery server 150, or both, can associate log entries that reference the same document and identify the XP-Function, XP-Chain, and end-to-end process involved in that document.

[0077] Figure 13 This is a schematic diagram of a UI 1300 for navigating among process areas, processes, functions, transactions, programs, interfaces, batch jobs, and roles, according to some example embodiments. UI 1300 includes a header 1310; buttons 1330A, 1330B, 1330C, 1330D, and 1330E in a function process view area 1320; buttons 1350A, 1350B, 1350C, 1350D, and 1350E in an end-to-end process view area 1340; and buttons 1370A, 1370B, 1370C, 1370D, 1370E, and 1370F in a library area 1360. The header 1310 indicates that UI 1300 is displaying data about an autodiscovered process. UI 1300 is generated using data generated from the autodiscovery of executed processes.

[0078] Each of buttons 1330A-1330E, 1350A-1350E, and 1370A-1370F is operable to display another UI with more details about the XP-Function or process associated with the button. Functional processes can be automatically organized hierarchically, with functional areas at the highest level, followed by functional processes, process sets, and XP-Chains at the lowest level. For example, the XP-Function for a standard order can be associated with a leaf node in the hierarchy of Delivery / Sales / Order / Standard Order. For example, button 1330D is operable to display a UI with information about the XP-Function (accessed from XP-Function table 510) in the "Sales" functional process.

[0079] Each of buttons 1350A-1350E is associated with an end-to-end process. For example, button 1350A is operable to display more information about the "O2C" or "Order to Cash" process. End-to-end processes are assembled using a bottom-up approach. Depending on the core functional area of ​​the end-to-end process, tables or log files are selected and accessed. For example, the Order to Cash process is in the "Sales" core functional area, while the "P2P" or "Purchase to Payment" process is in the "Purchasing" core functional area.

[0080] For each event that creates a document, the document number of the created document and the XP-Function that created the document are identified. The document number is used to identify other XP-Functions that access or modify the document. Furthermore, if the event that created the document operates on a parent document, the relationship between the parent document and the created document is recorded (e.g., stored in a database table). If no parent document exists, the XP-Function that created the document is the starting XP-Function of the end-to-end process, and the XP-Chain containing that XP-Function is the starting XP-Chain. If a parent document exists, the XP-Function and the corresponding XP-Chain are not the starting XP-Function, and the tracing of the process continues backward through the preceding XP-Function.

[0081] In either case, the automatic process discovery components 125A-125B, process discovery module 230, or both follow the document flow via XP-Functions, from the first XP-Function and corresponding XP-Chain that initiates the process to the last XP-Function and corresponding XP-Chain that operates on the document without creating sub-documents. For example, a sequence of XP-Functions can create standard orders, delivery documents, transfer orders, invoices, accounting documents, lean returns, return delivery documents, return credit notes, and another accounting document. By operating one of the buttons 1350A-1350E, another UI displaying the indicated type of process is shown. By selecting a separate end-to-end process, additional information about the components of the XP-Function, XP-Chain, document, or any suitable combination thereof is displayed.

[0082] Button 1370A is operable to display a UI with additional information about the discovered XP-Function. Each XP-Function is stored once in a library. The library can be organized hierarchically, with functional areas at the highest level, followed by functional procedures, procedure sets, and XP-Chains at the lowest level. For example, the XP-Function for a standard order can be associated with the leaf node of the hierarchy: Delivery / Sales / Order / Standard Order.

[0083] XP-Functions categorized as "Reports" or "Send / Receive Interface Functions" can be used for multiple functional processes and corresponding end-to-end processes. In some example embodiments, naming conventions can be used to identify such XP-Functions. For example, "IDoc:Receive" can be used at the beginning of an XP-Function name to indicate that the XP-Function receives interface messages for subsequent events during the triggering process, or "IDoc:Send" can be used at the beginning of an XP-Function name to indicate that the XP-Function sends interface messages for subsequent events during the triggering process. The core of XP-Function names is automatic identification from key XP-Cell data elements. Data element names can be combined completely or partially and inserted exactly as they are represented in the application server or database server being analyzed. This allows end users to easily identify and analyze processes because their names automatically reflect what they have seen in the system while executing the process. Other methods use advisory knowledge or functional process archiving to hard-code any objects identified in the system logs, remapping or manually mapping them to process steps.

[0084] UI 1300 can be used by business users who want to navigate and analyze discovered processes and XP-Functions using buttons 1330A-1330E in the Functional Process View area 1320 and buttons 1350A-1350E in the End-to-End Process View area 1340. Additionally, UI 1300 can be used by IT users who want to navigate and analyze discovered processes and XP-Functions using buttons 1370A-1370F in the Library area 1360.

[0085] Figure 14 This is a schematic diagram of a UI 1400 for displaying functionality during execution, according to some example embodiments. UI 1400 includes a header 1410; headers 1420, 1425, 1430, 1440, 1450, 1460, 1470, and 1480; and result rows 1490A, 1490B, 1490C, and 1490D. Header 1410 indicates that UI 1400 is displaying data from a process discovery repository. UI 1400 is generated using data produced from the automatic discovery of executed processes and can respond to... Figure 13 The operation of button 1330B is displayed.

[0086] Headers 1440-1480 indicate that each of the result lines 1490A-1490D includes information for the XP-Function: the name of the function, the XP-Chain to which the XP-Function is part, the sequential position of the XP-Function within the XP-Chain, the XP-Cell corresponding to the XP-Function, and the key executable object providing the XP-Function. Furthermore, headers 1420, 1425, and 1430 indicate the functional areas, functional procedures, and procedure sets provided within the XP-Chain. Functional areas are aggregations of procedures executed within the same highest-level application component. Therefore, functional areas help users navigate the UI to find procedures, procedure sets, XP-Chains, or XP-Functions of interest. Functional procedures are logical categories within functional areas. Figure 14 In the example, the "Sales" function process is located within the "Delivery" function area. In some example embodiments, additional columns are displayed for the date and time of the last use of the XP-Function.

[0087] As visible in UI 1400, each of the XP-Functions in the resulting rows 1490A-1490D is part of the "MTO Standard Order" XP-Chain, which resides in the "Order" process set, the "Sales" function process, and the "Delivery" function area. The "MTO Standard Order" XP-Chain begins with a sales order for a free item created by a dialog user (row 1490A) or a sales order for a standard item created by an automated background job (row 1490B), as indicated by the sequence value 1 for each of these two XP-Functions. Within this XP-Chain, the second XP-Function is a sales order modifying a free item, while the third XP-Function is a sales order modifying a standard item.

[0088] XP-Cell values ​​can be generated by concatenating multiple values ​​to produce a unique string that can be meaningfully parsed. For example, the first character of each XP-Cell value is either "A" or "B". According to User Type Table 440, "A" indicates that the key executable object corresponding to the XP-Cell is executed by a dialog (e.g., interactive), while "B" indicates that the key executable object is executed by the system (e.g., programming). As another example, each XP-Cell includes either "_I_" or "_U_". "_I_" indicates that an object was created, while "_U_" indicates that an object was modified.

[0089] This allows for continuous (near real-time) monitoring of dashboard information for end-to-end processes, XP-Chain, and XP-Functions. UI 1400 is an example of such a continuously monitored dashboard. As the process discovery server 150 collects additional information, rows 1490A-1490D are updated. Additional rows are added in response to the detection of additional XP-Functions, and existing rows are removed in response to the detection that an XP-Function has not been used for a predetermined period of time (e.g., one week or one month), or both. The analysis and reporting module 260 can be used to analyze the consistency of configured roles, the usage and consistency of document types, the importance of document types that must be tested (CBM0 handles 100,000 items, while ZCB0 handles 10 items), the usage of standard and custom transactions, the number of transactions running most / few processes, the simultaneous execution of the same / same XP-Function by automated batch jobs and dialogs, the consistency of processes configured differently in the system for the same end-to-end scenario (repeated configuration means repeated system ownership costs), and the critical end-to-end of the test scope (e.g., 30 out of 200 scenarios run 90% of the business).

[0090] Standard process discovery is typically based on event logs from a single software system. This is often insufficient to capture the entire business process. One might use other software systems (e.g., XP-Functions provided by a second software system) as part of their daily work. Compared to traditional log-file-based backend process mining, the example systems and methods described in this paper combine data collected simultaneously from multiple sources across multiple software systems, including application servers and related database servers. For example, analyzing a single log file might identify a single XP-Chain, but not an end-to-end process involving multiple XP-Chains across multiple application servers 120A-120B. Instead, by analyzing log files across multiple application servers 120A-120B and correlating XP-Chains based on modified documents, end-to-end processes are identified.

[0091] A system that only analyzes application server log files can identify events but not the corresponding data logs on the database server. The application server contains all processing log files for complete and incomplete process events (e.g., system workloads). For example, if a user initiates the creation of a sales order and stops midway for any reason without saving and sending the order, the application log file will contain all executed objects triggered by the user; similarly, if an interface message is received in the system and canceled without publishing a message to create a purchase order, the application log file will contain all executed objects for this incomplete event. By analyzing only application server logs, events that did not occur may be included in the process, while the correct process steps cannot be identified. Database server logs may not contain executable objects, especially for initial events such as document creation, automated events in processes executed via batch jobs, interfaces, or both. By analyzing only database logs, many executables for process steps cannot be identified.

[0092] In some example embodiments, the process discovery module 230 of the process discovery server 150 assigns a name to an XP-Function based on information collected from log files, a database, or both. The names of the relevant process data elements are combined, either entirely or partially, and inserted into the XP-Function name exactly as they are represented in the application server or database server being analyzed. For example, the name might have the format <Executable Type>_<Document Type>_<Document Category>__<Project Category>_<User Type>_<Task Type>. The reconstructed process discovery naming convention can be easily understood and recognized by the system users, owners, testers, analysts, or anyone else analyzing the system.

[0093] To illustrate, the name `DialogCreate_TA_C_VBAK_CBXN_A_I` will be assigned to an executable XP-cell of type dialog that performs a creation task for a document of type TA in category C. The document's data is stored in table VBAK, the item category is CBXN, the user type is A, and the task type is I. The strings in the XP-cell name can be mapped to and the corresponding XP-function defined and created, which has the name `Dialog:Create Standard Order`, `Service Item`, `VBAK`. For example, document category C could refer to an order document, document type TA could refer to a standard order, table VBAK could refer to the Sales Document:Header Data table, item category CBXN could refer to a service item, user type A could refer to a manual user type, and so on.

[0094] Another example XP-Function name is Batch:Create Standard Delivery,StandardItem,LIKP, which is derived from XP-Cell BatchCreate_LF_J_WithoutWM_TAN_A_I. This XP-Function name indicates an executable type of Batch, which performs a creation task on LF documents in category J. The document's data is not stored in a table (as indicated by the WithoutWM flag), the item category is TAN, the user type is A, the task type is I, and the warehouse management flag (not included in the previous example) is WithoutWM. The table can refer to LIKP, i.e., SD Document:Delivery Header Data. In this example, document category J refers to delivery documents, document type LF refers to standard deliveries, and item category TAN refers to standard items. By defining XP-Functions in this way, the detailed name of the end-to-end scenario in which the XP-Function is executed can be identified.

[0095] The attributes assigned by XP-Function can include components such as: system identifier, client identifier, user type, transaction code, procedure, number of transactions or procedures, role, authorized object, authorized fields and field values, number of items, number of documents, material type, organizational structure object, date and timestamp of creation or modification, place used in the procedure, table name text, table fields used, or any suitable combination thereof.

[0096] Data collected from log files, database tables, or both includes document number, project number, document type, document category, organizational structure, purchase order number, sender port, receiver port, message, message attributes, process code, including XP-Function functional modules, roles, authorized objects, timestamps, or any suitable combination thereof. The collected data is used to identify XP-Functions, associate XP-Functions with documents, associate XP-Functions with roles, associate XP-Functions with predecessor XP-Functions, associate XP-Functions with successor XP-Functions, associate XP-Functions with XP-Chain, associate XP-Functions with end-to-end processes, or any suitable combination thereof.

[0097] Figure 15 This is a schematic diagram of UI 1500 for displaying functionality during execution, according to some example embodiments. UI 1500 includes a header 1510; an information area 1515; headers 1520, 1525, 1530, 1540, 1550, 1560, 1570, and 1580; and result rows 1590A, 1590B, and 1590C. Header 1510 indicates that UI 1500 is displaying data from a process discovery repository. Like UI 1400, UI 1500 is generated using data generated from the automatic discovery of executed processes.

[0098] Information area 1515 indicates that result lines 1590A-1590C are the same end-to-end process (order to cash, in...) Figure 15 In the example, this includes a portion of the same end-to-end scenario (“O2C: For MTO standard orders, standard items, expected invoicing, expected pricing orders”), and a portion of the same functional area (“Delivery”). In some example embodiments, these three columns are shown as additional headers with values ​​shown for each of the result rows 1590A-1590C.

[0099] Headers 1530-1580 indicate that each of the result rows 1590A-1590D includes information for the XP-Function: the name of the function, the XP-Chain to which the XP-Function is part, the sequential position of the XP-Function within the XP-Chain, the XP-Cell corresponding to the XP-Function, and the key executable object providing the XP-Function. Additionally, headers 1520 and 1525 indicate the functional procedures and procedure sets provided by the XP-Chain. In some example embodiments, additional columns showing the date and time of the last use of the XP-Function are displayed. An XP-Chain sequence column, containing the sequence of XP-Chains within the end-to-end scenario, may also be displayed. Example values ​​for the XP-Chain sequences in result rows 1590A-1590C are 1, 1, and 2, respectively.

[0100] As can be seen in UI 1500, each of the XP-Functions in result lines 1590A-1590B is part of the "MTO Standard Order" XP-Chain, which resides in the "Order" process set, the "Sales" functional process, and the "Delivery" functional area. This XP-Chain begins with the "Batch Create Order, MTO Standard Order, Standard Item" XP-Function (Sequence 1), followed by the "Dialogue Change Order, MTO Standard Order, Standard Item" XP-Function (Sequence 2). The XP-Function in result line 1590C is part of the "Standard Invoice" XP-Chain, which resides in the "Invoice" process set, the "Invoicing" functional process, and the "Delivery" functional area. The "Dialogue Create Invoice, Standard Invoice, Standard Item" XP-Function (Sequence 3) follows the XP-Function in line 1590B in the end-to-end scenario.

[0101] Result line 1590C shows that the "Dialog Box Create Invoice, Standard Invoice, Standard Item" XP-Function is part of the "Standard Invoice" XP-Chain within the "Invoice" procedure set of the "Invoicing" function process in the "Delivery" functional area. Although it is in a different functional process and procedure set, this XP-Function is in the same functional area, end-to-end scenario, and end-to-end procedure as the XP-Functions in lines 1590A-1590B.

[0102] Figure 16This is a schematic diagram of a UI 1600 for displaying the execution process of a discovery, according to some example embodiments. UI 1600 includes a header 1610; an information area 1620; XP-Chain elements 1630, 1640, 1650, and 1660; and a button 1670. UI 1600 displays information about a set of XP-Chains including the end-to-end process E2E001, as indicated in the labels of the information area 1620 and header 1610. In some example embodiments, a UI including a list of discovery processes may be presented before the display of UI 1600. In response to the selection of one of the discovery processes, UI 1600 is displayed, including information about the selected process.

[0103] The two sequences of the XP-Chain are presented as different options for performing an end-to-end process. In one sequence, XP-Chain chain001 is followed by XP-Chain chain002 and ends with XP-Chain chain004 (as shown in XP-Chain elements 1630, 1640, and 1660). In the second sequence, XP-Chain chain003 is inserted between XP-Chain chain002 and XP-Chain chain004 (as shown in XP-Chain elements 1630-1660).

[0104] Each XP-Chain is a series of XP-Functions executed by a single application server 120A-120B. Therefore, the end-to-end process E2E001 is executed by different functions on at least two and up to four different application servers.

[0105] Button 1670 is operable to cause the creation of test scripts that test the end-to-end process being viewed in UI 1600. For example, in response to the operation of button 1670, all test scripts in the XP-Chain shown in the test information area 1620 can be generated. The test scripts can be automatically deployed to test device 170 and executed periodically by test device 170.

[0106] Figure 17 This is a schematic diagram of a UI 1700 for displaying a functional chain discovered during execution, according to some example embodiments. UI 1700 includes a header 1710; an information area 1720; and XP-Function elements 1730, 1740, and 1750. UI 1700 displays information about a set of XP-Functions, including XP-Chain chain001, as indicated in the labels of information area 1720 and header 1710.

[0107] like Figure 17 As shown, XP-Chain chain001 includes XP-Function func001, XP-Function func002, and XP-Function func003 executed in this order (as shown in XP-Function elements 1730-1750). Since each XP-Chain is a series of XP-Functions executed by a single application server, Figure 17 All three XP-Functions shown are executed on a single application server.

[0108] Figure 18 This is a flowchart illustrating the operations of a method 1800 suitable for automatically performing a discovery process and generating test scripts for the discovery process, according to some example embodiments. Method 1800 includes operations 1810, 1820, 1830, 1840, and 1850. By way of example and not limitation, method 1800 is described as being... Figure 1-20 The device, module, and database are executed.

[0109] In operation 1810, process discovery component 125A, process discovery module 230, or both access first data identifying the first process step from a first log file of a first application server (e.g., application server 120A), a database server (e.g., database server 130A), or both. The first data indicates a first change to a document associated with a process including the first and second process steps. For example, data corresponding to... Figure 17 The data for XP-Function element 1730. XP-Function func001 is part of XP-Chain chain001, which is part of the end-to-end process E2E001, as... Figures 16-17 As shown. In some example embodiments, the data accessed is text identifying key executable objects, function names, and documentation. For example, and referring to... Figure 15 The result line 1590C: "Dialogue Create Invoice, Standard Invoice, Standard Item; VF01".

[0110] The first log file may be an SQL log storing data for Structured Query Language (SQL) commands sent to or executed by a database server (e.g., database server 130A), a call monitoring log storing data for functions performed by an application server (e.g., application server 120A), a workload log monitoring the workload of the application server, a business transaction log storing data about objects being manipulated by functions or the database, or any suitable combination thereof.

[0111] The first log file can contain millions of records, covering all processes and system background activities. Some log entries refer to executed transactions that were performed without saving the data. For example, a user might create an order but change their mind and exit the transaction without saving, creating a log entry without an associated document. These log entries can be skipped. Therefore, XP-Functions can be defined based on associated fields such as task type, timestamp, date, system identifier, client identifier, or any suitable combination thereof. Log file entries can be associated with XP-Function database records to determine which XP-Function each log file entry references. Since log files can be periodically deleted (e.g., every 24 or 48 hours), data about discovered XP-Functions, XP-Chains, or processes can be stored in a database that uses... Figures 3-9 The database in pattern 300 is used for persistent storage. In some example embodiments, a UI is presented to the user, illustrating the relationship between the XP-Function and the executable file.

[0112] In some example embodiments, process steps are run by system transactions. For example, the system may use transaction VA01 or FioriApp (AppID F1814) and VA01 in the order creation process step. Regardless of how the order is created, the system database (e.g., in application data 135A) will have a record of the order (e.g., with identifier SO000123) being saved, but the database does not save a record of which executable object was used at the application layer. Therefore, additional data collected by the process discovery component (e.g., process discovery component 125A) and stored in process discovery data (e.g., process discovery data 140A) supplements the application's own logs. As a result, process discovery server 150 can collect process discovery data and link it to tasks that reflect business events. Thus, when an event occurs, process discovery server 150 is able to identify process steps and the executables that execute them.

[0113] In operation 1820, process discovery module 230 updates the database based on first data to store first process steps and first relationships between processes. For example, data can be added to one or more of the process discovery table 310, XP-Function table 510, XP-Chain table 610, and process set table 640. Process set table 640 stores relationships between processes and XP-Chains, while XP-Chain table 610 stores relationships between XP-Chains and XP-Functions (each XP-Function corresponds to a process step).

[0114] In operation 1830, process discovery module 230 accesses second data from a second log file of a second application server (e.g., application server 120B) to identify second process steps, the second data indicating second changes to a document. For example, data corresponding to... Figure 17 The data for XP-Function element 1740. XP-Function func002 is part of XP-Chainchain001, and XP-Chainchain001 is part of the end-to-end process E2E001, as... Figures 16-17 As shown. In some example embodiments, the data accessed is text identifying key executable objects, function names, and documentation. For example, and referring to... Figure 15 The result line 1590B: "Dialogue Change Order, MTO Standard Order, Standard Item; VA02".

[0115] In operation 1840, process discovery module 230 updates the database based on second data to store second process steps and second relationships between processes.

[0116] In operation 1850, test creation module 240 generates test scripts for the process based on the stored first relation and the stored second relation. For example, the generated test scripts may invoke both the first process step (e.g., XP-Function) and the second process step based on the fact that both process steps are part of the discovered process.

[0117] After the test script is created, the communication module 210 provides the test script to the test server or test client (e.g., client device 160B). The test script is then executed automatically to detect errors during the discovery process.

[0118] Therefore, by using method 1800, log files recording the functions provided by different application servers are aggregated to determine the constituent process steps of the process. By comparing with manual processes, the use of automation to discover end-to-end processes saves time and effort. Furthermore, since process discovery is based on data collected from multiple application servers, database servers, or both, rather than from a single application server or a single database server, more complex end-to-end processes can be discovered, further saving time and effort for users of the automated process discovery server and the computational resources involved in manually associating process steps executed on different servers.

[0119] It should be noted that a process may include optional or alternative steps that are not executed in every iteration of the process. Therefore, multiple execution paths for the process may exist. Historical log files covering several months and millions of records can be analyzed to observe past events and automatically reconstruct the executed process. Over time, this method is used to observe and map the complete state space of the process. Therefore, the process discovery system described in this paper is automated and scalable.

[0120] In view of the above-described implementation of the subject matter, this application discloses examples in the following list, wherein an isolated example of a feature or a combination of more than one feature of an example, and optionally, a combination with one or more features of one or more further examples, are also further examples falling within the disclosure of this application.

[0121] Example 1 is a method comprising: one or more processors accessing first data from a first log file to identify a first process step, the first data indicating a first change to a document associated with a process including the first process step and a second process step; updating a database based on the first data to store a first relationship between the first process step and the process; one or more processors accessing second data from a second log file to identify a second process step, the second data indicating a second change to the document; updating the database based on the second data to store a second relationship between the second process step and the process; and generating a test script for the process based on the stored first relationship and the stored second relationship.

[0122] In Example 2, the subject of Example 1 includes: rendering a user interface on a display device, the user interface including an option to generate a test script; and wherein generating the test script is in response to the selection of the option.

[0123] In Example 3, the subject of Examples 1-2 includes, wherein: updating the database to store the first process step and the first relationship between the process includes updating rows in the database, the rows of which also store identifiers of the chain of process steps executed on a single application server and values ​​indicating the position of the first process step relative to the other steps in the chain.

[0124] In Example 4, the topic of Example 3 includes: running test scripts.

[0125] In Example 5, the topics of Examples 1-4 include, where: the first process step is an executable process function (XP-Function).

[0126] In Example 6, the subject matter of Examples 1-5 includes, wherein: accessing the first log file includes accessing the first log file from a first server via a network; and accessing the second log file includes accessing the second log file from a second server via a network.

[0127] In Example 7, the subject of Examples 1-6 includes: the database is a first database; and the example also includes: accessing third data from a second database to identify a third process step, the third data showing changes to a second document; and updating the first database based on the third data to store a third relationship between the third process step and the process.

[0128] In Example 8, the topics of Examples 1-7 include, where: the first process step includes user interaction.

[0129] In Example 9, the topics of Examples 1-8 include, where: the first process step includes automated interaction.

[0130] In Example 10, the subject matter of Examples 1-9 includes, where: the first data also identifies roles associated with the first process step.

[0131] Example 11 is a system comprising: a memory storing instructions; and one or more processors configured by the instructions to perform operations including: accessing first data from a first log file identifying a first process step, the first data indicating a first change to a document associated with a process including the first process step and a second process step; updating a database based on the first data to store a first relationship between the first process step and the process; accessing second data from a second log file identifying a second process step, the second data indicating a second change to the document; updating the database based on the second data to store a second relationship between the second process step and the process; and generating a test script for the process based on the stored first relationship and the stored second relationship.

[0132] In Example 12, the subject of Example 11 includes, wherein the operation further includes: rendering a user interface on a display device, the user interface including an option to generate a test script; and wherein generating the test script is in response to the selection of the option.

[0133] In Example 13, the subject of Examples 11-12 includes, wherein: updating the database to store the first process step and the first relationship between the process includes updating rows in the database, the rows of which also store identifiers of the chain of process steps executed on a single application server and values ​​indicating the position of the first process step relative to the other steps in the chain.

[0134] In Example 14, the topics of Examples 11-13 include, where the operation also includes: running the test script.

[0135] In Example 15, the subject of Examples 11-14 includes, where: the first process step is an executable process function (XP-Function).

[0136] In Example 16, the subject of Examples 11-15 includes, wherein: accessing a first log file includes accessing the first log file from a first server via a network; and accessing a second log file includes accessing the second log file from a second server via a network.

[0137] In Example 17, the subject matter of Examples 11-16 includes, wherein: the database is a first database; and the operation further includes: accessing third data from a second database to identify a third process step, the third data indicating changes to a second document; and updating the first database based on the third data to store a third relationship between the third process step and the process.

[0138] Example 18 is a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: accessing first data from a first log file identifying a first process step, the first data indicating a first change to a document associated with a process including the first process step and a second process step; updating a database based on the first data to store a first relationship between the first process step and the process; accessing second data from a second log file identifying a second process step, the second data indicating a second change to the document; updating the database based on the second data to store a second relationship between the second process step and the process; and generating a test script for the process based on the stored first relationship and the stored second relationship.

[0139] In Example 19, the subject of Example 18 includes, wherein the operation further includes: rendering a user interface on a display device, the user interface including an option to generate a test script; and wherein generating the test script is in response to the selection of the option.

[0140] In Example 20, the subject of Examples 18-19 includes, wherein: updating the database to store the first process step and the first relationship between the process includes updating the rows of the database, the rows of the database also storing identifiers of the chain of process steps executed on a single application server and values ​​indicating the position of the first process step relative to the other steps in the chain.

[0141] Example 21 is at least one machine-readable medium containing instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-20.

[0142] Example 22 is an apparatus that includes means for implementing any of Examples 1-20.

[0143] Example 23 is a system for implementing any of Examples 1-20.

[0144] Example 24 is a method for implementing any of Examples 1-20.

[0145] Figure 19 This is a block diagram 1900 illustrating an example of a software architecture 1902 for a computing device. Architecture 1902 can be used in conjunction with, for example, various hardware architectures as described herein. Figure 19 This is merely a non-limiting example of a software architecture, and many other architectures can be implemented to facilitate the functionality described herein. A representative hardware layer 1904 is shown and can be represented, for example, any of the aforementioned computing devices. In some examples, it can be based on... Figure 19 The architecture of the computer system is used to implement the hardware layer 1904.

[0146] Representative hardware layer 1904 includes one or more processing units 1906 having associated executable instructions 1908. The executable instructions 1908 represent executable instructions of software architecture 1902, including implementations of the methods, modules, subsystems, and components described herein, and may also include memory and / or storage modules 1910 that also have executable instructions 1908. Hardware layer 1904 may also include other hardware as indicated by other hardware 1912, which represents any other hardware of hardware layer 1904, such as other hardware shown as part of software architecture 1902.

[0147] exist Figure 19 In the example architecture, software architecture 1902 can be conceptualized as a stack of layers, where each layer provides specific functionality. For example, software architecture 1902 may include layers such as: operating system 1914, libraries 1916, framework / middleware 1918, applications 1920, and presentation layer 1944. Operablely, applications 1920 and / or other components within a layer can enable application programming interface (API) calls 1924 through the software stack, and in response to API calls 1924, access responses, return values, etc., as indicated by message 1926. The layers shown are representative in nature, and not all software architectures have all layers. For example, some mobile or dedicated operating systems may not provide a framework / middleware layer 1918, while other operating systems may provide such a layer. Other software architectures may include additional or different layers.

[0148] Operating system 1914 can manage hardware resources and provide public services. Operating system 1914 may include, for example, kernel 1928, services 1930, and drivers 1932. Kernel 1928 can act as an abstraction layer between the hardware layer and other software layers. For example, kernel 1928 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. Service 1930 can provide other public services to other software layers. In some examples, service 1930 includes interrupt services. Interrupt services can detect the receipt of an interrupt and, in response, cause architecture 1902 to suspend its current processing and execute an interrupt service routine (ISR) when the interrupt is accessed.

[0149] Driver 1932 can be responsible for controlling or interfacing with the underlying hardware. For example, depending on the hardware configuration, driver 1932 may include a display driver, a camera driver, etc. Drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), Drivers, NFC drivers, audio drivers, power management drivers, etc.

[0150] Library 1916 provides common infrastructure that can be utilized by applications 1920 and / or other components and / or layers. Library 1916 typically provides functionality that allows other software modules to perform tasks in a way that is easier than directly interfaced with the underlying operating system 1914 functions (e.g., kernel 1928, services 1930, and / or drivers 1932). Library 1916 may include system libraries 1934 (e.g., the C standard library), which provide functions such as memory allocation functions, string manipulation functions, and mathematical functions. Furthermore, Library 1916 may include API libraries 1936, such as media libraries (e.g., libraries for supporting the rendering and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG), graphics libraries (e.g., OpenGL frameworks for rendering 2D and 3D graphics content on a display), database libraries (e.g., SQLite providing various relational database functionalities), web libraries (e.g., WebKit providing web browsing functionality), and so on. Library 1916 can also include a wide variety of other libraries 1938 to provide many other APIs to applications 1920 and other software components / modules.

[0151] Framework / Middleware 1918 can provide higher-level public infrastructure that can be utilized by Application 1920 and / or other software components / modules. For example, Framework / Middleware 1918 can provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. Framework / Middleware 1918 can provide a wide range of other APIs that can be utilized by Application 1920 and / or other software components / modules, some of which may be specific to a particular operating system or platform.

[0152] Application 1920 includes built-in application 1940 and / or third-party application 1942. Examples of representative built-in applications 1940 may include, but are not limited to, contact applications, browser applications, book reader applications, location applications, media applications, messaging applications, and / or game applications. Third-party applications 1942 may include any of the built-in applications 1940 and a wide variety of other applications. In specific examples, third-party applications 1942 (e.g., those used by entities other than platform-specific vendors using Android) TM Or iOS TM Applications developed using a Software Development Kit (SDK) can run on mobile operating systems such as iOS. TM Android TM , Mobile software running on the operating system of a telephone or other mobile computing device. In this example, a third-party application 1942 may enable API calls 1924 provided by a mobile operating system such as operating system 1914 to facilitate the functionality described herein.

[0153] Application 1920 can utilize built-in operating system functions (e.g., kernel 1928, services 1930, and / or drivers 1932), libraries (e.g., system library 1934, API library 1936, and other libraries 1938), and frameworks / middleware 1918 to create user interfaces for interaction with the system's user. Alternatively or additionally, in some systems, user interaction may occur through a presentation layer (such as presentation layer 1944). In these systems, the application / module "logic" can be decoupled from the aspects of the application / module that interact with the user.

[0154] Some software architectures utilize virtual machines. Figure 19In the example, this is illustrated by virtual machine 1948. The virtual machine creates a software environment in which applications / modules can execute as if they were running on a hardware computing device. The virtual machine is hosted by a host operating system (operating system 1914) and typically (though not always) has a virtual machine monitor 1946, which manages the operation of virtual machine 1948 and its interface with the host operating system (i.e., operating system 1914). Software architectures execute within virtual machine 1948, such as operating system 1950, libraries 1952, frameworks / middleware 1954, applications 1956, and / or presentation layers 1958. These layers of the software architecture executing within virtual machine 1948 may be the same as the corresponding layers described previously, or they may be different.

[0155] Modules, components and logic

[0156] Some embodiments are described herein as including logic or multiple components, modules, or mechanisms. Modules may constitute software modules (e.g., (1) code embodied on a non-transitory machine-readable medium or (2) in transmitted signals) or hardware-implemented modules. Hardware-implemented modules are tangible units capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (e.g., standalone, client, or server computer systems) or one or more hardware processors may be hardware-implemented modules configured by software (e.g., an application or application portion) to operate to perform certain operations described herein.

[0157] In various embodiments, hardware-implemented modules can be implemented mechanically or electronically. For example, a hardware-implemented module may include dedicated circuitry or logic permanently configured to perform certain operations (e.g., as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware-implemented module may also include programmable logic or circuitry temporarily configured by software to perform certain operations (e.g., as contained within a general-purpose processor or another programmable processor). It will be understood that the decision to implement a hardware-implemented module mechanically in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software), may be driven by cost and time considerations.

[0158] Therefore, the term "hardware-implemented module" should be understood to include tangible entities that are physically constructed, permanently configured (e.g., hardwired), or temporarily or provisionally configured (e.g., programmed) for operating and / or performing certain operations described herein in a certain manner. Considering embodiments where hardware-implemented modules are provisionally configured (e.g., programmed), each of the hardware-implemented modules does not need to be configured or instantiated at any given time. For example, in cases where the hardware-implemented modules include a general-purpose processor configured using software, the general-purpose processor can be configured as a correspondingly different hardware-implemented module at different times. The software can accordingly configure the processor, for example, to constitute a specific hardware-implemented module at one time instance and a different hardware-implemented module at different time instances.

[0159] Hardware-implemented modules can provide information to and receive information from other hardware-implemented modules. Therefore, the described hardware-implemented modules can be considered communicatively coupled. When multiple such hardware-implemented modules exist simultaneously, communication can be achieved through signal transmission (e.g., through appropriate circuitry and buses connecting the hardware-implemented modules). In embodiments where multiple hardware-implemented modules are configured or instantiated at different times, communication between such hardware-implemented modules can be achieved, for example, through the storage and retrieval of information in a memory structure that has been accessed by the multiple hardware-implemented modules. For example, one hardware-implemented module can perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. Another hardware-implemented module can then access that memory device at a later time to retrieve and process the stored output. Hardware-implemented modules can also initiate communication with input or output devices and can operate on resources (e.g., collections of information).

[0160] The various operations of the example methods described herein can be performed at least in part by one or more processors, which are either temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors can constitute processor-implemented modules that operate to perform one or more operations or functions. In some example embodiments, the term "module" herein may include processor-implemented modules.

[0161] Similarly, the methods described herein can be implemented, at least in part, by a processor. For example, at least some of the operations of the methods can be performed by one or more processors or modules implemented by processors. The execution of certain operations can be distributed across one or more processors, not only residing within a single machine but also deployed across multiple machines. In some example embodiments, one or more processors may be located in a single location (e.g., in a home environment, office environment, or server farm), while in other embodiments, the processors may be distributed across multiple locations.

[0162] One or more processors may also operate to support the execution of related operations in a “cloud computing” environment or as “Software as a Service (SaaS)”. For example, at least some of these operations may be executed by a group of computers (as an example of a machine including processors) that are accessible via a network (e.g., the Internet) and via one or more appropriate interfaces (e.g., APIs).

[0163] Electronic devices and systems

[0164] The example embodiments may be implemented in digital electronic circuits, or in computer hardware, firmware, or software, or in a combination thereof. The example embodiments may be implemented using computer program products, such as computer programs tangibly embodied in an information carrier (e.g., in a machine-readable medium) for execution by or control of the operation of a data processing apparatus (e.g., a programmable processor, a computer, or a plurality of computers).

[0165] Computer programs can be written in any programming language (including compiled or interpreted languages) and can be deployed in any form, including as standalone programs or as modules, subroutines, or other units suitable for use in a computing environment. Computer programs can be deployed to execute on one or more computers distributed at one site or across multiple sites and interconnected by a communication network.

[0166] In the example embodiments, the operations may be performed by one or more programmable processors executing a computer program to perform the function by manipulating input data and generating output. The method operations may also be performed by dedicated logic circuitry (e.g., an FPGA or ASIC), and the apparatus of the example embodiments may be implemented as dedicated logic circuitry.

[0167] Computing systems may include clients and servers. Clients and servers are generally geographically isolated and typically interact via a communication network. The client-server relationship is generated by computer programs running on the respective computers and having a client-server relationship with each other. In embodiments of deploying programmable computing systems, it will be understood that both hardware and software architectures are worth considering. Specifically, it will be understood that the choice of implementing certain functions in permanently configured hardware (e.g., ASICs), temporarily configured hardware (e.g., a combination of software and programmable processors), or a combination of permanently and temporarily configured hardware can be a design choice. The hardware (e.g., machines) and software architectures that can be deployed in various example embodiments are listed below.

[0168] Example machine architecture and machine-readable media

[0169] Figure 20 This is a block diagram of a machine in the form of an example computer system 2000, within which instructions 2024 can be executed to cause the machine to perform any or more of the methodologies discussed herein. In alternative embodiments, the machine operates as a standalone device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate as a server or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), tablet PC, set-top box (STB), personal digital assistant (PDA), cellular phone, web device, network router, switch, or bridge, or any machine capable of executing instructions (sequentially or otherwise) specifying actions to be taken by the machine. Furthermore, although only a single machine is shown, the term "machine" should also be understood to include any collection of machines that individually or jointly execute a set (or more) of instructions to perform any or more of the methodologies discussed herein.

[0170] Example computer system 2000 includes a processor 2002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), main memory 2004, and static memory 2006, which communicate with each other via a bus 2008. Computer system 2000 may also include a video display unit 2010 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Computer system 2000 also includes an alphanumeric input device 2012 (e.g., a keyboard or touch-sensitive display), a user interface (UI) navigation (or cursor control) device 2014 (e.g., a mouse), a storage unit 2016, a signal generation device 2018 (e.g., a speaker), and a network interface device 2020.

[0171] Machine-readable media

[0172] Storage unit 2016 includes machine-readable medium 2022 on which one or more sets of data structures and instructions 2024 (e.g., software) embodying or utilized by any or more of the methodologies or functions described herein are stored. Instructions 2024 may also reside wholly or at least partially within main memory 2004 and / or processor 2002 during execution thereon by computer system 2000, wherein main memory 2004 and processor 2002 also constitute machine-readable medium 2022.

[0173] Although the machine-readable medium 2022 is shown as a single medium in the example embodiments, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more instructions 2024 or data structures. The term "machine-readable medium" should also be understood to include any tangible medium capable of storing, encoding, or carrying instructions 2024 for execution by a machine and enabling the machine to perform any or more methodologies of this disclosure, or capable of storing, encoding, or carrying data structures utilized by or associated with such instructions 2024. Therefore, the term "machine-readable medium" should be understood to include, but is not limited to, solid-state storage, as well as optical and magnetic media. Specific examples of machine-readable media 2022 include: non-volatile memory, including, as examples, semiconductor memory devices (e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices); magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disc read-only memory (CD-ROM) and digital versatile disc read-only memory (DVD-ROM). Machine-readable media are not transmission media.

[0174] transmission medium

[0175] Instructions 2024 can also be sent or received on the communication network 2026 using a transmission medium. Instructions 2024 can be sent using a network interface device 2020 and any of a variety of well-known transmission protocols (e.g., Hypertext Transfer Protocol (HTTP)). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, mobile phone networks, common-use telephone (POTS) networks, and wireless data networks (e.g., WiFi and WiMax networks). The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions 2024 for machine execution, as well as other intangible media that include digital or analog communication signals or facilitate communication with such software.

[0176] Although specific exemplary embodiments have been described herein, it will be apparent that various modifications and alterations can be made to these embodiments without departing from the broader spirit and scope of this disclosure. Therefore, the specification and drawings are to be considered illustrative rather than limiting. The accompanying drawings, which form a part of this document, illustrate specific embodiments that can be practiced in an illustrative rather than limiting manner. The illustrated embodiments have been described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments can be utilized and derived therefrom, such that structural and logical substitutions and changes can be made without departing from the scope of this disclosure. Therefore, the detailed description should not be considered limiting, and the scope of the various embodiments is defined only by the appended claims and the full scope of their equivalents.

[0177] For convenience only, these embodiments of the subject matter of this invention may be referred to herein individually and / or collectively as the term "invention," and if more than one invention or inventive concept is disclosed in fact, it is not intended to voluntarily limit the scope of this application to any single invention or inventive concept. Therefore, although specific embodiments have been shown and described herein, it should be understood that any arrangement calculated to achieve the same purpose may replace the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of the various embodiments. Combinations of the above embodiments, as well as other embodiments not specifically described herein, will be apparent to those skilled in the art upon reading the above description.

[0178] Some parts of the subject matter discussed herein can be presented as algorithms or symbolic representations of operations on data stored in machine memory (e.g., computer memory) as bit or binary digital signals. Such algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the art of data processing to communicate the substance of their work to others of similar skill in the art. As used herein, an "algorithm" is a self-consistent sequence of operations or similar processing that leads to a desired result. In this context, algorithms and operations involve the physical manipulation of physical quantities. Typically, but not necessarily, these quantities may take the form of electrical, magnetic, or optical signals that can be stored, accessed, transmitted, combined, compared, or otherwise manipulated by a machine. Primarily for general reasons, it is sometimes convenient to use terms such as "data," "content," "bit," "value," "element," "symbol," "character," "item," "number," "number," etc., to refer to such signals. However, these terms are merely convenient labels and must be associated with appropriate physical quantities.

[0179] Unless otherwise specified, the use of terms such as “processing,” “computing,” “operation,” “determining,” “presenting,” and “displaying” herein can refer to the actions or processes of a machine (e.g., a computer) that manipulates or transforms data, which is represented as a physical (e.g., electrical, magnetic, or optical) quantity within one or more memories (e.g., volatile memory, non-volatile memory, or any suitable combination thereof), registers, or other machine components that receive, store, transmit, or display information. Furthermore, unless otherwise specified, as is common in patent documents, the terms “a” and “an” are used herein to include one or more instances. Finally, as used herein, unless otherwise specified, the conjunction “or” means a non-exclusive “or.”

Claims

1. A method for automatic discovery of a process for execution, comprising: accessing, by one or more processors, first data from a first log file that identifies a first process step, the first data showing a first change to a document associated with a process, the process comprising the first process step and a second process step; updating a database to store a first relationship between the first process step and the process by adding the first data to the database, wherein the first data comprises a process set identifier that identifies a process and a first identifier that identifies the first process step; accessing, by the one or more processors, second data from a second log file that identifies a second process step, the second data showing a second change to the document; updating the database to store a second relationship between the second process step and the process by adding the second data to the database, wherein the second data comprises the process set identifier that identifies a process and a second identifier that identifies the second process step; and generating a test script for the process based on the stored first relationship and the stored second relationship, wherein accessing the first log file comprises accessing the first log file from a first server via a network, and wherein accessing the second log file comprises accessing the second log file from a second server via the network.

2. The method of claim 1, further comprising: causing a user interface to be presented on a display device, the user interface comprising an option to cause the test script to be generated; and wherein generating the test script is in response to selection of the option.

3. The method of claim 1, wherein: updating the database to store the first relationship between the first process step and the process comprises updating a row of the database that also stores an identifier of a chain of process steps executed on a single application server and a value indicating a position of the first process step relative to other steps of the chain.

4. The method of claim 3, further comprising: running the test script.

5. The method of claim 1, wherein: the first process step is an executable process function XP-Function.

6. The method of claim 1, wherein, the first process step comprises a user interaction.

7. The method of claim 1, wherein, the first process step comprises an automated interaction.

8. The method of claim 1, wherein, the first data further identifies a role identifier of a role associated with the first process step.

9. A system for automatic discovery of a process for execution, comprising: a memory that stores instructions; and one or more processors configured by the instructions to perform operations comprising: accessing first data from a first log file that identifies a first process step, the first data showing a first change to a document associated with a process, the process comprising the first process step and a second process step; updating a database to store a first relationship between the first process step and the process by adding the first data to the database, wherein the first data comprises a process set identifier that identifies a process and a first identifier that identifies the first process step; accessing, by the one or more processors, second data from a second log file that identifies a second process step, the second data showing a second change to the document; updating the database to store a second relationship between the second process step and the process by adding the second data to the database, wherein the second data comprises the process set identifier that identifies a process and a second identifier that identifies the second process step; and generating a test script for the process based on the stored first relationship and the stored second relationship, wherein accessing the first log file comprises accessing the first log file from a first server via a network, and wherein accessing the second log file comprises accessing the second log file from a second server via the network. accessing, from a second log file, second data identifying a second process step, the second data showing a second change to the document; updating the database to store a second relationship between the second process step and the process by adding the second data to the database, wherein the second data includes a process set identifier identifying a process and a second identifier identifying the second process step; and generating a test script for the process based on the stored first relationship and the stored second relationship, wherein accessing the first log file includes accessing the first log file from a first server via a network, and wherein accessing the second log file includes accessing the second log file from a second server via the network.

10. The system of claim 9, wherein, The operations further include: causing a user interface to be presented on a display device, the user interface including an option to cause the test script to be generated; and wherein generating the test script is in response to selection of the option.

11. The system of claim 9, wherein: updating the database to store the first relationship between the first process step and the process includes updating a row of the database that also stores an identifier of a chain of process steps executed on a single application server and a value indicating a position of the first process step relative to other steps of the chain.

12. The system of claim 9, wherein, The operations further include: running the test script.

13. The system of claim 9, wherein: the first process step is an executable process function XP-Function.

14. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: accessing, from a first log file, first data identifying a first process step, the first data showing a first change to a document associated with a process, the process including the first process step and a second process step; updating the database to store a first relationship between the first process step and the process by adding the first data to the database, wherein the first data includes a process set identifier identifying a process and a first identifier identifying the first process step; accessing, from a second log file, second data identifying a second process step, the second data showing a second change to the document; updating the database to store a second relationship between the second process step and the process by adding the second data to the database, wherein the second data includes a process set identifier identifying a process and a second identifier identifying the second process step; and generating a test script for the process based on the stored first relationship and the stored second relationship, wherein accessing the first log file includes accessing the first log file from a first server via a network, and wherein accessing the second log file includes accessing the second log file from a second server via the network.

15. The non-transitory computer-readable medium of claim 14, wherein, The operations further include: causing a user interface to be presented on a display device, the user interface including an option to cause the test script to be generated; and wherein generating the test script is in response to selection of the option. wherein generating the test script is in response to selection of the option.

16. The non-transitory computer-readable medium of claim 14, wherein: updating the database to store the first relationship between the first process step and the process includes updating a row of the database that also stores an identifier of a chain of process steps executed on a single application server and a value indicating a position of the first process step relative to other steps of the chain.

Images