Where the application boundary is drawn around the Robot/ File Transfer System, and the Robot is not considered part of the underlying technical infrastructure of another application, how should the robot functionality be counted?
While each robot performs a specific set of functions, a number of generic function types have been identified.These include:
- Functions to automate the process of logging on to multiple applications.A robot can maintain simultaneous sessions with multiple applications.In some cases Log-off functions are also considered robot business functions.
- Predefined "hotkeys" which automate the transfer of data from nominated fields within a specific screen in one host application to appropriate fields in another screen/s within a different host application.The receiving screen is then subject to the normal validation and processing rules of that system.During the transition the robot application may modify the information according to business rules to ensure compatibility with the system into which the data is being pasted, or to automate a business process.This operation is termed "screen scraping".One data transfer may involve:
- Data transfer in one direction only:
- Source system to Receiving system; or
- Receiving system response to source system
- Multiple data movements between Source system, Robot and Receiving system, before the elementary process (data transfer) is considered to have achieved a business goal and left the business of the application in a consistent state.
- Functions that log into a receiving application, call particular screens and generate their own transaction data from data and rules stored internally within the robot.
- Functions that transfer control from one system to another.
- Functions that log and/or queue/prioritise transactions.
- Functions that record the responses of the receiving application, both internally within the robot and transfer responses to other systems.
- Functions that ensure system security: Source system, robot and receiving system.
- Functions which schedule the processing events
Issues to be addressed include:
- When the purpose of the count is to size the functionality offered by the robot, do normal IFPUG rules apply and if so, how should it be counted?
- Should every data flow, which crosses the boundary of the robot, be counted as a transaction?
- Can the rule files which govern robot behaviour be counted as Reference Tables or do they define "underlying" transaction processing and therefore get counted as a transaction implementation issue?
GENERAL DISCUSSION AND RESOLUTION
The functionality offered by robots can be counted using IFPUG 4.1 guidelines.The FP Analyst applies the IFPUG definitions to the transactions that enter and leave the application boundary and to the data stored within the application boundary.
However, not every data flow that crosses the boundary of the robot is necessarily a unique elementary process.As stated above, one function may involve multiple data movements between Source system, robot and receiving system, as the data required to complete the transaction is created by iteration.The condition that the transaction "achieve a business goal and leave the business of the system in a consistent state" is relevant and should be applied.
The sole objective of a Robot application is to function as a "virtual" system user and to mimic the way a user would interface between systems.Actions that occur within one application may require a business ‘reaction’ in another application.However this action/reaction sequence is more complicated than a simple transfer of data.Depending upon conditions existing in either the source, or receiving system, a user would be required to make decisions on the appropriate system to access (data from/data to), the data content of the transfer, expected sequence of system responses and how to respond to error conditions.All this user decision-making functionality must be built into the Robot.
Note: The following list of functions are intended to be a generic guide for counting this type of application, there may be instances where particular applications may offer more or less functionality.
Files: Internal Logical Files
Where they exist, the following may be counted asILFs for the Robot System:
- Configuration Files
Specifies the attributes of the Robot and associated systems and automates the log on/log off functions.
- Queues/Transaction files
The Robot may be required to keep a copy of all data transfers and update the status of these records.
- Security Files
Normal system security that defines Users and User Profiles. (See Section 3.2.5, Security.)
Files: External Interface Files
Where they exist, the following may be counted asEIFs for the Robot System:
- Screens scraped from
These are the screens on the Source applications that the Robot collects data transfer information from.
- Screens pasted to
These are only counted where the data transfer function involves multiple data movements, i.e. where the provision of the data by the Robot is an iterative process.Based on responses from the receiving screen/s the robot provides the necessary data to complete the data transfer.
- Screens enquired upon
Where the function of the Robot is to facilitate an enquiry upon a host system, the file enquired upon is counted as an EIF.If a logical file cannot be identified, count the host system screen as the EIF.
Transactions: External Inputs
Any user identifiable transactions required to create or maintain Internal Logical Files may be counted asEIs for the Robot system.
Transactions: External Outputs
Where they exist, the following may be counted asEOs for the Robot system:
- Transactions that are sent outside the application boundary that automate logging into the host application. There may be one EO per host application, so check for uniqueness.
- Transactions that are sent outside the application boundary, navigate to an appropriate host application screen and transfer data to that screen.There may be one EO per screen, so check for uniqueness.Typically a robot will have a very small number of such transactions
These transactions usually have multiple action/reaction sequences. which are governed by the Rule tables.The source system screens from which the data is scraped (EIFs) are counted as FTRs on the EO transaction.
- Transactions that are sent outside the application boundary navigate to an appropriate host application screen. There may be one EO per screen, so check for uniqueness.In some cases the Robot is simply required to position the user within the correct application screen.There is no automated data transfer involved.
The output transactions of a robot are counted as External Outputs rather than External Inquiries.While there may not be any calculated data within the data transfer, the generation of the data and/or data transformations usually involve complex logical processing and are therefore defined as derived data.
The file transfer transactions are logically one EO transaction. They typically collect the required data, pass it through the File Transfer application, perhaps recording the transfer event, perhaps reformatting the data, and pass it on to the destination system.
The main distinction, which needs to be made for a File Transfer System, is to determine whether the system has knowledge of the data that it is transferring. (Robots do). Where the system transfers complete files, with no regard to the file format or contents, regardless of how many files are transferred, between how many systems, there is only one generic transaction. Where different logical processing can be demonstrated, because the FT system is ‘aware’ of the data being transferred, then multiple transactions can be counted.
Transactions: External Enquiries
Any user identifiable transactions required to view/display data on ILFs or (non-screen) EIFs may be counted asEQs for the Robot System. Count as per IFPUG guidelines.