Claims:1. A processor-implemented method for processing a transaction having a plurality of tasks executable at a plurality of distinct applications, the method comprising:
characterizing, via one or more hardware processors, a transaction data associ-ated with the processing of the transaction through the plurality of distinct appli-cations by systematically arranging the transaction data in a configuration file us-ing an optimization model, the transaction data comprising a transaction workflow and a plurality of rules for processing of the transaction;
characterizing, via the one or more hardware processors, application status of at least one application from the plurality of distinct applications by identifying, in real-time, a response of the at least one application to at least one task from the plurality of tasks executable at the at least one application; and
processing, via the one or more hardware processors, the transaction by:
enabling communication amongst the plurality of distinct applications for execution of the plurality of tasks by using application specific handlers corre-sponding to the plurality of distinct applications, and
executing the at least one task based on the application status and the transaction data associated with the at least one application.

2. The method as claimed in claim 1, further comprising:
identifying the application status of the at least one application as undefined in the configuration file;
learning at least one new rule for execution of the at least one task correspond-ing to the undefined application status; and
updating the configuration file with the at least one new rule.

3. The method as claimed in claim 2, wherein learning the at least one new rule com-prises enabling a user-input for providing the at least one new rule using an interac-tive graphical user interface (GUI).

4. The method as claimed in claim 1, wherein the application status for executing the at least one task comprises application statuses including application readiness, ap-plication’s session expiry during transaction processing, application failure, status of processing the at least one task as one of success and failure, error conditions and alternate flows, network failure, application non-response to user-actions, and delay in application response.

5. The method as claimed in claim 1, wherein the plurality of applications comprises Green screen mainframe application, browser based application, client-server type application or standalone desktop application.

6. The method as claimed in claim 1, wherein the optimization model comprises at least one of a random optimization model, a minimum load model, a round-robin model, and a weighted round-robin model.

7. The method as claimed in claim 6, further comprising enabling selection of the op-timization model via an interactive graphical user interface.

8. A system for processing a transaction having a plurality of tasks executable at a plurality of distinct applications, the system comprising:
one or more memories storing instructions; and
one or more hardware processors coupled to the one or more memories, where-in said one or more hardware processors are configured by said instructions to
characterize a transaction data associated with the processing of the transaction through the plurality of distinct applications by systematically arrang-ing the transaction data in a configuration file using an optimization model, the transaction data comprising a transaction workflow and a plurality of rules for processing of the transaction;
characterize application status of at least one application from the plu-rality of distinct applications by identifying in real-time a response of the at least one application to at least one task from the plurality of tasks executable at the at least one application; and
process the transaction by enabling communication amongst the plurali-ty of distinct applications for execution of the plurality of tasks by using applica-tion specific handlers corresponding to the plurality of distinct applications and executing the at least one task based on the application status and the transaction data associated with the at least one application.

9. The system as claimed in claim 8, wherein the one or more hardware processors are further configured by the instructions to:
identify the application status of the at least one application as undefined in the configuration file;
learn at least one new rule for execution of the at least one task corresponding to the undefined application status; and
update the configuration file with the at least one new rule.

10. The system as claimed in claim 9, wherein to learn the at least one new rule, the one or more hardware processors are further configured by the instructions to ena-ble a user-input for providing the at least one new rule using an interactive graph-ical user interface (GUI).

11. The system as claimed in claim 8, wherein the application status for executing the at least one task comprises application statuses including application readiness, ap-plication’s session expiry during transaction processing, application failure, status of processing the at least one task as one of success and failure, error conditions and alternate flows, network failure, application non-response to user-actions, and delay in application response.

12. The system as claimed in claim 8, wherein the plurality of applications comprises Green screen mainframe application, browser based application, client-server type application or standalone desktop application.

13. The system as claimed in claim 8, wherein the optimization models comprises at least one of a random optimization model, a minimum load model, a round-robin model, and a weighted round-robin model.

14. The system as claimed in claim 13, wherein the one or more hardware processors are further configured by the instructions to enable selection of the optimization model via an interactive graphical user interface.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)

Title of invention:
METHOD AND SYSTEM FOR AUTOMATIC PROCESSING OF TRANSACTIONS SPANNING ACROSS MULTIPLE APPLICATIONS

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th Floor,
Nariman Point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the invention and the manner in which it is to be performed.
TECHNICAL FIELD
[001] The present subject matter relates, in general, to transaction processing and, in particular, to providing method and systems for automatic processing of transactions spanning across multiple applications of distinct types.

BACKGROUND
[002] Currently, transaction processing systems are extensively utilized in multitude of businesses for managing data, for instance business-sensitive data. For example, the transaction processing systems are utilized in banks, travel companies, and other such businesses. The accuracy of business sensitive data is of prime importance for such businesses for ensuring smooth running of their operations, thus utmost care is taken that the transaction processing systems are designed in a manner to ensure that the business sensitive data is properly entered and updated.
[003] Existing transaction processing systems involves intensive manual effort and includes repetitive nature of work. In order to improve the productivity and efficiency of operation, Robots (or robotic systems) plays an important role to bring automation of tasks involved in transaction processing. Typically, the robots are machine which perform the repetitive and frequent task such as data entry in a faster way. However, existing robotic systems face technical challenges for performing transactions. For example, the typical robots are just machines that lack capability to take decisions and act upon certain business conditions.
SUMMARY
[004] The following presents a simplified summary of some embodiments of the disclosure in order to provide a basic understanding of the embodiments. This summary is not an extensive overview of the embodiments. It is not intended to identify key/critical elements of the embodiments or to delineate the scope of the embodiments. Its sole purpose is to present some embodiments in a simplified form as a prelude to the more detailed description that is presented below.
[005] In view of the foregoing, in one aspect, a method for processing a transaction having a plurality of tasks executable at a plurality of distinct applications is provided. A processor-implemented method for processing the transaction include characterizing, via one or more hardware processors, a transaction data associated with the processing of a transaction through a plurality of distinct applications, wherein characterizing the transaction data comprises systematically arranging the transaction data in a configuration file using an optimization model, the transaction data comprising a transaction workflow and a plurality of rules for processing of the transaction. Further the method includes characterizing, via the one or more hardware processors, application status of at least one application from the plurality of distinct applications, wherein characterizing the application status of the at least one application comprises identifying in real-time a response of the at least one application to at least one task from the plurality of tasks executable at the at least one application. Furthermore, the method includes processing, via the one or more hardware processors, the transaction by enabling communication amongst the plurality of distinct applications for execution of the plurality of tasks by using application specific handlers corresponding to the plurality of distinct applications, and executing the at least one task based on the application status of the at least one application and the transaction data.
[006] In another aspect, a system for processing a transaction having a plurality of tasks executable at a plurality of distinct applications is provided. The system includes one or more memories storing instructions; and one or more hardware processors coupled to the one or more memories. The one or more hardware processors are configured by said instructions to characterize a transaction data associated with the processing of a transaction through a plurality of distinct applications, wherein characterizing the transaction data comprises systematically arranging the transaction data in a configuration file using an optimization model, the transaction data comprising a transaction workflow and a plurality of rules for processing of the transaction. Further, the one or more hardware processors are configured by said instructions to characterize application status of at least one application from the plurality of distinct applications, wherein characterizing the application status of the at least one application comprises identifying in real-time a response of the at least one application to at least one task from the plurality of tasks executable at the at least one application. Furthermore, the one or more hardware processors are configured by said instructions to process the transaction by enabling communication amongst the plurality of distinct applications for execution of the plurality of tasks by using application specific handlers corresponding to the plurality of distinct applications, and executing the at least one task based on the application status of the at least one application and the transaction data.
[007] In yet another aspect, a non-transitory computer-readable medium having embodied thereon a computer program for executing a method for processing a transaction having a plurality of tasks executable at a plurality of distinct applications is disclosed. The method includes characterizing, via one or more hardware processors, a transaction data associated with the processing of a transaction through a plurality of distinct applications, wherein characterizing the transaction data comprises systematically arranging the transaction data in a configuration file using an optimization model, the transaction data comprising a transaction workflow and a plurality of rules for processing of the transaction. Further the method includes characterizing, via the one or more hardware processors, application status of at least one application from the plurality of distinct applications, wherein characterizing the application status of the at least one application comprises identifying in real-time a response of the at least one application to at least one task from the plurality of tasks executable at the at least one application. Furthermore, the method includes processing, via the one or more hardware processors, the transaction by enabling communication amongst the plurality of distinct applications for execution of the plurality of tasks by using application specific handlers corresponding to the plurality of distinct applications, and executing the at least one task based on the application status of the at least one application and the transaction data.

BRIEF DESCRIPTION OF THE FIGURES
[008] The detailed description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the drawings to reference like features and modules.
[009] FIG. 1 is an example of processing of a transaction in a typical business process is illustrated.
[0010] FIG. 2 illustrates a block diagram of a system for processing of a transaction spanning across multiple applications, in accordance with an example embodiment.
[0011] FIG. 3 illustrates an example architecture diagram of a system for transaction processing, in accordance with an example embodiment.
[0012] FIG. 4 is a flow diagram depicting an example method for processing of a transaction spanning across multiple applications, in accordance with an example embodiment.
[0013] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems and devices embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

DETAILED DESCRIPTION
[0014] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0015] The present disclosure relates to a systems and methods for processing of transaction involving decision making in multiple applications. Herein, the term ‘transaction’ may refer to a multi-task process being performed by a system that involves performing multiple tasks spanning over multiple applications. Such a system that is configured to perform processing of a transaction may be referred to as a transaction processing system. The transaction processing system may include hardware and software that may be collectively configured to host an IT application for performing transactions pertaining to a process or industry. The transaction processing systems may include systems that manage airline reservations, payroll, employee records, banking activities, manufacturing, shipping, and so on.
[0016] During transaction processing in a business or a bank, there are a number of scenarios whereby a transaction is split into multiple tasks and each of the tasks is performed on a distinct application. Typically since the tasks are to be performed at multiple applications, an associate may spend substantial amount of time in data entry kind of repetitive operations while extracting meaningful data and filtering out unwanted data. The involvement of human activity introduces error and inaccuracy in operations resulting in lower output at slower speed. In addition, the associate may work with various types of applications at a time and transfer data from one application to another; however the typical robotic system has limitations working on multiple applications at a time, and thus passing data between applications needs human intervention. For example, data received from a web page need to be entered partially in ERP and CRM application needs data cleaning and business rules. Additionally, in certain scenarios, the process of transaction is to be performed in a particular order and may include holding/waiting times before the application completes a specific step and starts a new step on other application. However, it may be challenging for a typical robotic system to predict and estimate the holding and/or waiting time so as to control tracking of data as well as applications. An example of a typical transaction being performed on multiple distinct applications is described further with reference to FIG. 1.
[0017] Referring to FIG. 1, an example of processing of a transaction in a typical business process 100 is illustrated. Herein, the applications are considered to be Information Technology (IT) applications. Additionally, a business process has several flows including main, alternate, error flows, and so on. As shown in FIG. 1, a typical business process includes various flows and execution activities (marked as ‘step’); decision making points based on application responses, d1…d4; and End – multiple end states including success flows and alternate flows (illustrated as ‘end’). A typical robot system may be expected to understand application response and take actions based on them. In addition, the typical robot system may need to check application readiness, sessions’ expiry, and delays in responses and so on, and handle them appropriately. Moreover, to execute a business process, the typical robot system needs to interact with several types of applications. Examples of said applications may include, but are not limited to, green screen or Mainframe application, web-browser based application, client-server type application or standalone desktop application, and so on. However, a particular technical challenge with typical robotic systems is that said systems are not capable of predicting and controlling tracking of data as well as the applications across which the transaction is spanned.
[0018] Various embodiments presented herein disclose systems and methods for processing transactions in a robust and accurate manner. The methods and systems are not limited to the specific embodiments described herein. In addition, the method and system can be practiced independently and separately from other modules and methods described herein. Each device element/module and method can be used in combination with other elements/modules and other methods.
[0019] Various embodiments of the present disclosure provide methods and systems for processing of a transaction spanning across a plurality of applications of distinct types. The system is capable of facilitating inter-process communication amongst the multiple applications. Examples of types of said applications includes but are not limited to, green screen (Mainframe application), browser based application, client-server type application, standalone desktop application, and so on. In an embodiment, the system is capable of utilizing various handlers that can work with various business applications. The system leverages the handlers such as Selenium's for Web based Applications and IBM Connect for mainframe applications. In an embodiment, the handlers are also utilized to detect the business application delay, process failure and network failure.
[0020] The system can be trained for decision making and helps in inter process communications. The system is capable of understanding and learning application types of said multiple applications, and extract and/or fill relevant data from/to said applications, in order to process the transaction. The system utilizes machine learning to automatically enable real-time decision making for extracting and/or filling the relevant data. The system provides ability to take decisions based on various conditions happening in the environment like application response, network failure, process failure, process abnormal terminations, delay in business applications and process not responding to user actions. In an embodiment, the system includes a configuration file that stores a plurality of rules for handling various scenarios and take decisions accordingly. In addition, the disclosed system can be implemented as an extremely light weight engine, and can run with minimal over heads. An example block diagram of the transaction processing system for performing processing of transactions is described further with reference to FIG. 2.
[0021] The manner, in which the system and method for processing transactions shall be implemented, has been explained in details with respect to the FIGS. 2 through 4. While aspects of described methods and systems for processing transactions can be implemented in any number of different systems, utility environments, and/or configurations, the embodiments are described in the context of the following exemplary system(s). Herein, the transaction may be related to a business/service/entity/enterprise.
[0022] FIG. 2 illustrates a block diagram of a system 200 for transaction processing associated with an application, in accordance with an example embodiment. In an example embodiment, the system 200 may be embodied in, or is in direct communication with a computing device. The system 200 includes or is otherwise in communication with one or more hardware processors such as a processor 202, one or more memories such as a memory 204, and a user interface 206. The processor 202, memory 204, and a user interface 206 may be coupled by a system bus such as a system bus 208 or a similar mechanism.
[0023] The one or more memories such as the memory 204, may store instructions, any number of pieces of information, and data, used by a computer system, for example the system 200 to implement the functions of the 200. The memory 204 may include for example, volatile memory. Examples of volatile memory may include, but are not limited to volatile random access memory (RAM). The non-volatile memory may additionally or alternatively comprise an electrically erasable programmable read only memory (EEPROM), flash memory, hard drive, or the like. Some examples of the volatile memory includes, but are not limited to, random access memory, dynamic random access memory, static random access memory, and the like. Some example of the non-volatile memory includes, but are not limited to, hard disks, magnetic tapes, optical disks, programmable read only memory, erasable programmable read only memory, electrically erasable programmable read only memory, flash memory, and the like. The memory 204 may be configured to store information, data, applications, instructions or the like for enabling the system 200 to carry out various functions in accordance with various example embodiments. Additionally or alternatively, the memory 204 may be configured to store instructions which when executed by the processor 202 causes the system 200 to behave in a manner as described in various embodiments.
[0024] The one or more hardware processors such as the processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that facilitates in managing access to a financial account. Further, the processor 202 may comprise a multi-core architecture. Among other capabilities, the processor 202 is configured to fetch and execute computer-readable instructions or modules stored in the memory 204. The processor 202 may include circuitry implementing, among others, audio and logic functions associated with the communication. For example, the processor 202 may include, but are not limited to, one or more digital signal processors (DSPs), one or more microprocessor, one or more special-purpose computer chips, one or more field-programmable gate arrays (FPGAs), one or more application-specific integrated circuits (ASICs), one or more computer(s), various analog to digital converters, digital to analog converters, and/or other support circuits. The processor 202 thus may also include the functionality to encode messages and/or data or information. The processor 202 may include, among other things, a clock, an arithmetic logic unit (ALU) and logic gates configured to support operation of the processor 202. Further, the processor 202 may include functionality to execute one or more software programs, which may be stored in the memory 204 or otherwise accessible to the processor 202.
[0025] In an example embodiment, the user interface 206 is in communication with the processor 202. Examples of the user interface 206 include but are not limited to, input interface and/or output user interface. The input interface is configured to receive an indication of a user input. The output user interface provides an audible, visual, mechanical or other output and/or feedback to the user. Examples of the input interface may include, but are not limited to, a keyboard, a mouse, a keypad, a touch screen, soft keys, and the like. Examples of the output interface may include, but are not limited to, a display such as light emitting diode display, thin-film transistor (TFT) display, liquid crystal displays, active-matrix organic light-emitting diode (AMOLED) display, a microphone, a speaker, ringers, vibrators, and the like. In an example embodiment, the user interface 206 may include, among other devices or elements, any or all of a speaker, a microphone, a display, and a keyboard, touch screen, or the like. In this regard, for example, the processor 202 may comprise user interface circuitry configured to control at least some functions of one or more elements of the user interface 206, such as, for example, a speaker, ringer, microphone, display, and/or the like. The processor 202 and/or user interface circuitry comprising the processor 202 may be configured to control one or more functions of one or more elements of the user interface 206 through computer program instructions, for example, software and/or firmware, stored on a memory, for example, the one or more memories 204, and/or the like, accessible to the processor 202.
[0026] In an example embodiment, the processor 202 is configured to, with the content of the memory 204, and optionally with other components described herein, to cause the system 200 to receive a request to initiate processing of one or more transactions. Herein, each of the one or more transactions may span across a plurality of applications of distinct types. Herein, “transaction spanning across a number of applications” may refer to execution of a transaction having a number of distinct tasks at the multiple distinct applications. For example, execution of a transaction to process a loan request may include a task of entering loan number on a green screen application which may return one or many loan applicants, a task of entering name of each applicant on a web browser based application which validates it and returns name of employer, a task of entering name of the employer on Applet which returns office name, a task of entering name of the applicant on desktop based .NET application which provides applicant’s salary, and a task of providing a final report of loan number and details of each applicant captured from above-referenced applications printed in say a word document by a desktop based .NET application. As described in the present example, the system 200 sequentially executes said tasks at a plurality of distinct applications such as green screen (Mainframe application), browser based application, client-server type application or standalone desktop application.
[0027] As is seen above, the transaction involves various steps or tasks that are spanned across multitude of distinct applications. A table below indicates various exemplary inputs provided to each of the distinct applications and corresponding example outputs received from said inputs.

Application Type Input Output
Green Screen Loan No Applicant First name & Last Name
Web browser EmpName Employer
Applet Employer Office Name
.NET –Desktop Emp Name Salary
.NET –Desktop Loan No Final word document

[0028] Herein, in order to sequentially execute the plurality of tasks at multiple distinct applications, the system 200 enables inter-process communication amongst the multitude of distinct applications using application specific handlers corresponding to the set of applications, as will be described later with reference to FIG. 3.
[0029] The system 200 executes the plurality of tasks at the plurality of applications by characterizing a transaction data associated with the processing of a transaction. The transaction data includes at least a transaction workflow and a plurality of rules for processing of the transaction. The transaction workflow may define details of various tasks to be executed at various applications. Herein, characterizing the transaction data includes systematically arranging the transaction data in a configuration file using an optimization model. The optimization model may facilitate in arranging the transaction data in a most optimized manner in the configuration file. Examples of the optimization model may include, but are not limited to, random optimization model, minimum load model, round-robin model, weighted round-robin model, and so on.
[0030] As discussed, the configuration file may include systematically arranged transaction data associated with the transactions. Herein, systematically arranging the transaction data in the configuration file refers to storing various execution steps on each of the set of applications, as granular as possible, in a logical order. In an embodiment, the execution steps may be recorded and stored in the configuration file without any decision making action. Based on the information (derived from the transaction data) in the configuration file, the system 200 interprets output of various steps involved in the processing of the transaction, such as errors occurred in transaction related applications, end of reparation loops, successful completion of all the steps of the transaction, and so on. In an embodiment, the configuration file is created using an interactive graphical user interface (GUI) such as the UI 206. Herein, it will be understood that storing the execution steps in configuration file without decision making actions facilitates in making the application configurable. In addition, in case of any change in business process, the steps can be re arranged in the configuration file without changing them.
[0031] The system 200 characterizes application status of at least one application from the plurality of distinct applications. Herein, characterizing the application status of the at least one application includes identifying in real-time a response of the at least one application to at least one task from the plurality of tasks executable at the at least one application. For example, the system 200 may interpret the application response to scenarios such as application readiness, session’s expiry, delays in responses, and so on and further take actions to handle such scenarios based on the transaction data. For example, the system 200 may detect whether an application is ready to perform a task or not, or if there is a latency associated with performance of the task. The system 200 may further be capable of starting the application, in case said latency is detected.
[0032] The system 200 may direct application specific handlers to execute required steps at corresponding applications based on the transaction data recorded in the execution file. For example, in case of a mainframe application, the system can be trained using a corresponding handler to perform all required actions on green screen applications.
[0033] In another example, the system 200 may interpret the application response to scenarios such as application error flow. For instance, in case of a web-based application described in FIG. 1, validations on applicant details may be known only to web-based application and based on the response from application, error flow can be invoked. In the present scenario, the system 200 may detect whether the application is ready to perform a task or not, or if there is a latency associated with performance of the task. The system 200 may further be capable of starting the application, in case said latency is detected. Furthermore, the system 200 may be capable of invoking error flows if the need arises. For example, in case of business application, network errors and invalid input data resulting in errors in business applications, the system 200 may invoke error flows. The system 200 may direct application specific handlers to execute required steps at corresponding applications based on the transaction data recorded in the execution file. For example, in case of a web-based application, the system can be trained using a corresponding handler such as Selenium to perform all required actions thereon.
[0034] In yet another example, the system 200 may interpret the application response to scenario such as errors that may occur during applet loading. In the present scenario, the system 200 may detect errors and handles them appropriately. The system 200 may detect whether the applet has started. Further the system may be capable of starting the applet and wait for same, in case said latency is detected. In the present case, the system can be trained using a corresponding handler for handling the errors.
[0035] In still another example, the system 200 may interpret the application response to scenario such as starting and stopping of an application. For instance, the desktop Application takes significant resources while starting and stopping and so need to be started only if required. The system 200 may detect whether the application has started. Further, the system 200 may be capable of detecting application readiness, and launch it only if it is required. In the present case, the system can be trained using a corresponding handler for handling the starting and stopping the application.
[0036] As discussed above, the system 200 identifies application status for corresponding plurality of distinct applications, so that the task at said corresponding distinct application can be executed. In other words, the system 200 processes the transaction by executing the multiple tasks at the distinct applications based on the respective application status and the rules for execution of said tasks. Herein, the system 200 accesses the rules from the configuration file.
[0037] In an embodiment, the system 200 may identify the application status of the at least one application as undefined in the configuration file. Herein, the undefined status may indicate that an action corresponding to the identified the application status is not defined in the configuration file. In such a scenario, the system 200 may learn at least one new rule for execution of the task corresponding to the undefined application status. In an embodiment, the system 200 may learn the new rule(s) by a user input provided by user of the system 200. In an embodiment, the user input may be provided using the interactive GUI, for example the UI 206. The system 200 updates the configuration file with the new rule.
[0038] FIG. 3 illustrates an example architecture diagram 300 of a system, for example, the system 200 (FIG. 2) for transaction processing, in accordance with an example embodiment. As described previously, the system 200 can work with various types of applications together and perform inter-process communications, building a transaction and taking rollback decisions if applicable. For the purpose of description of inter-process communication, the architecture 300 includes application(s) 310, handler(s) 320 of the applications(s) 310, application(s) 330, handler(s) 340 of the applications(s) 330, a controller 350, an environment handler 352 and an operating system 354. The system can work with various types of applications together and perform the inter-process communications. Examples of said application types may include, but are not limited to, green screen, web browser and desktop based applications, applets running in browsers, and so on.
[0039] As is shown, inter-process communication between the applications 310 and 330 can be enabled through respective handlers, for example, the handlers 320, 340 respectively. For instance, for Web Browser Selenium is the handler, for .NET Applications UI Automation Framework is the handler, and for position Based scraping Re Mouse is the handler. In an embodiment, the system can be trained for various application statuses via the controller 350. In an example embodiment, the controller 350 may be embodied in the transaction processing system, for example, the system 200. The controller may also embody or may be in communication with a memory storing a configuration file, for example a configuration file 352. An example flow for processing of one or more transactions using the disclosed system architecture is described further in detail in FIG. 4.
[0040] FIG. 4 is a flow diagram depicting an example method 400 for transaction processing, in accordance with an example embodiment. The method 400 depicted in the flow chart may be executed by a system, for example, the system 200 of FIG. 2. In an example embodiment, the system 200 may be embodied in a computing device. Operations of the flowchart, and combinations of operation in the flowchart, may be implemented by various means, such as hardware, firmware, processor, circuitry and/or other device associated with execution of software including one or more computer program instructions. For example, one or more of the procedures described in various embodiments may be embodied by computer program instructions. In an example embodiment, the computer program instructions, which embody the procedures, described in various embodiments may be stored by at least one memory device of an apparatus and executed by at least one processor in the apparatus. Any such computer program instructions may be loaded onto a computer or other programmable apparatus (for example, hardware) to produce a machine, such that the resulting computer or other programmable apparatus embody means for implementing the operations specified in the flowchart. It will be noted herein that the operations of the method 400 are described with help of system 200. However, the operations of the method 400 can be described and/or practiced by using any other system.
[0041] At 402, the method 400 includes characterizing a transaction data associated with the processing of a transaction through a plurality of distinct applications. Herein, characterizing the transaction data includes systematically arranging the transaction data in a configuration file using an optimization model. Various examples of optimization model may include, but are not limited to, random optimization model, minimum load model, round-robin model, and weighted round-robin model. In an embodiment, the system 200 enables selection of the optimization model via an interactive graphical user interface, for example UI 206.
[0042] The transaction data may include a transaction workflow and a plurality of rules for processing of the transaction. Herein, the workflow may refer to a sequence of steps or tasks performed in a logical order for end-to-end processing of the transaction.
[0043] At 404, the method 400 includes characterizing application status of at least one application from the plurality of distinct applications. Herein, characterizing the application status of the at least one application includes identifying in real-time a response of the at least one application to at least one task from the plurality of tasks executable at the at least one application. The application status for executing the task comprises application statuses including application readiness, application’s session expiry during transaction processing, application failure, status of processing the task as one of success and failure, error conditions and alternate flows, network failure, application non-response to user-actions, and delay in application response.
[0044] In an embodiment, application status of the at least one application may be identified as undefined in the configuration file. In such a scenario, the system 200 may learn at least one new rule for execution of the task corresponding to the undefined application status. In an embodiment, the system 200 may learn the new rule(s) by a user input provided by user of the system 200. In an embodiment, the user input may be provided using the interactive GUI, for example the UI 206. The system 200 updates the configuration file with the new rule.
[0045] At 406, the method 400 includes processing the transaction by enabling communication amongst the plurality of distinct applications using application specific handlers corresponding to the plurality of distinct applications. Further the at least one task is executed based on the application status of the at least one application and the transaction data. An example scenario indicating a typical workflow and various tasks performed through various applications for processing of transaction at the plurality of distinct applications is described later in the description below.
Example Scenario:
[0046] In an example scenario for execution of a transaction to process a loan, said transaction may include plurality of tasks executable at plurality of distinct applications. For example, a task of entering loan number on a green screen application which may return one or many loan applicants, a task of entering name of each applicant on a web browser based application which validates it and returns name of employer, a task of entering name of the employer on Applet which returns office name, a task of entering name of the applicant on desktop based .NET application which provides applicant’s salary, and a task of providing a final report of loan number and details of each applicant captured from above-referenced applications printed in say a word document by a desktop based .NET application. As described in the present example, the disclosed system, for example the system 200 (FIG. 2) sequentially executes said tasks at a plurality of distinct applications such as green screen (Mainframe application), browser based application, client-server type application or standalone desktop application.
[0047] Typically, number of loan applicants associated to a specific loan number is known to green screen application only. Since green screen application takes significant time and resources in starting the application and, hence starting and stopping the green screen application for every loan number is challenging. The system 200 is configured to identify whether the green screen application is ready or not for processing of the respective task. In an embodiment, the system may access the configuration file to determine the rules corresponding to the green field application, and based on said rules, the system may determine application readiness of said application. If the system detects that the green screen application is not ready, then system may start the green screen application and wait till said application is ready for use. In addition, the system 200 may read configuration file to determine applicant details in indefinite loop till all applicant details are captured. The system can use a corresponding handler for training the system to perform various actions on green screen applications. For example, the system may utilize IBM Connections that provides API to perform actions similar to human agent, including mouse press, select, copy and paste clicking buttons, and so on.
[0048] Once application details are captured, then according to the workflow, the system may verify application details. Such details are known to Web based application. Based on response from application error, the workflow can be invoked. In case of any session error, the application may be unavailable for processing and hence application readiness is to be checked. The system detects whether the application is ready. The system may perform logging to the application only if it is required. The logging to application is typically required for example, when the application is logged off or session is invalid. The system facilitates in invoking error flow based on application response. The system handles invalid data errors and invokes error flows. The system detects successful completion of transactions based on either Popup, alerts, going to next URL, Message on Screen, and so on. In the present scenario, the system handles Ajax, Jquery and Dynamic HTML based controls. The system performs actions in infinite loop till all the data is processed. Herein, the system can be trained to perform all requisite actions of web-based applications by using handler, such as Selenium.
[0049] Once applicant details are identified, then according to the workflow, the system may perform a task of entering name of the employer on Applet which returns office name. Typical Applet loading can throw errors which need resolutions. The system has the ability of detect such errors, and handle them. For instance, the system may detect a warning box indicating the errors, and based on said detection system may handle such errors. In an example, a warning box may pop up indicating that “Your version of Java is out of date and an application running on our hard drive is requesting for a permission to run.” The warning box may provide more information for resolution of error as: “We recommend you to update Java using the button below. Click ‘Cancel’ to stop this app or ‘Run’ to allow it to continue”. Additionally, the system performs infinite loops to capture requisite data. The Applet running on desktop may include controls including, TextBox, Label, Button, Radio button, CheckBox, Data Grid, and dynamic controls.
[0050] Once the office name is retrieved, then based on the workflow, the system may perform a task of entering name of the applicant on desktop based .NET application which provides applicant’s salary. Once the applicant’s salary details are available, the system may perform a task of providing a final report of loan number and details of each applicant captured from above-referenced applications printed in say a word document by a desktop based .NET application. Herein, the system detects application readiness and launches it only if required. For example, when the said application is not ready already. The system understands application response and performs required actions.
[0051] Various embodiments of the present disclosure provide methods and systems for processing of transactions related to IT applications. For example, the disclosed system has the ability to take real-time decisions based on application responses for various distinct applications associated with the transaction. The system detects conditions such as session time out/session expiry, application readiness and application failures and take required actions. The system is capable of adapting for error and alternate flows. The system is capable of incorporating inter-process communication and can pass transaction data between the applications. The system can adapt and detect transaction status such as success/failure and take appropriate actions. The system can detect error conditions associated with transaction processing and respond accordingly. Moreover, the system can adapt and analyze environment and detect conditions like network failure, process non response to user actions, process delay and act on them. The system can perform graceful exits from applications and ensure smooth terminations of process. The system can detect system utilizations and act on the same. The system is extremely lightweight and fully configurable solution.
[0052] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[0053] It is, however to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0054] An important contribution of the disclosed embodiments is that the system is capable of enabling inter-process communication between the multiple of distinct application by utilizing application specific handlers. The inter-process communication between the distinct applications involved in processing of a task provides a technical solution to a technical problem of efficient handing of various application scenarios being dealt with by the robotic systems. The efficient handling of the tasks may include taking real-time decisions based on the business application’s responses, perform application ready ness verification, for all business applications, handle business application’s session expiry during transaction processing, detecting transaction status success/Failure, and ability to develop error handling scenario. As the disclosed system includes a configuration file in which the transaction data associated with the transaction is systematically stored, thereby enabling the system to readily access said data in real-time and process the transaction accordingly. Accordingly the system is capable of predicting and controlling tracking of transaction data as well as the applications across which the transaction is spanned. Additionally, the system can take decisions and act upon certain business conditions. The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[0055] The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
[0056] A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
[0057] The foregoing description of the specific implementations and embodiments will so fully reveal the general nature of the implementations and embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.
[0058] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.