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:

1. 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.
2. 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.

1. 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.
2. Functions that transfer control from one system to another.
3. Functions that log and/or queue/prioritise transactions.
4. Functions that record the responses of the receiving application, both internally within the robot and transfer responses to other systems.
5. Functions that ensure system security: Source system, robot and receiving system.
6. Functions which schedule the processing events

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.

• Configuration Files

Specifies the attributes of the Robot and associated systems and automates the log on/log off functions.

• Rule Tables

The possibilities are many and varied.They may include:

• Data transfer destination rules
• Page/screen/field navigation rules
• Page/screen/field recognition rules
• Validation rules
• Data conversion/translation tables
• Log/Event Files

Record data transfer traffic as it passes through the Robot.

• 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.)

• Other Reference files.

• Reference Files

(Those that have not been counted as ILFs.)

• 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 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.