System interfaces can be physically implemented in multiple ways. To what extent should the physical interface solution impact the business functions counted?

This section has been included to attempt to summarise a number of system interfacing scenarios, commonly encountered. Some of the issues have already been addressed in the Sections describing Front End Systems. They are repeated and summarised in this section primarily to provide an easy comparison of different scenarios and the resolutions of the counting issues relevant to the scenario.

To simplify the descriptions the following terms have been used

In each example it has been established that an application boundary exists between System A and System B.

Scenario 1

System A Enquiry on System B Files. System B handles the file access

This scenario is described in detail in Section 3.3.6 Duplicate Counting of Front-end and Core System Functions. An enquiry transaction initiated by System A, requires information from File Y in System B. This results in a request for information sent by A to System B. System B accesses File Y and sends a response with the required data to System A. System A displays the response data on a screen.

Scenario 1 Resolution

Transactions

Both System A and System B contribute to the enquiry function. Both count one EQ.

Neither system counts the messaging between the two applications i.e. the request and response messages.

A variation of this scenario occurs where multiple systems initiate the same EQ. All initiating systems count one EQ and System B counts one EQ only.

Files

There is only one file involved. System B counts File Y as an ILF. System A counts File Y as an EIF.

Scenario 2

System A Enquiry on System B Files. System A handles the file access

An enquiry transaction initiated by System A, requires information from File Y in System B. System A has all the functionality required to directly access the File Y. System A displays the response data on a screen

Scenario 2 Resolution

Transactions

System A has all the necessary functionality to deliver the complete enquiry function. System A counts one EQ.

There is no messaging between the two applications

Files

There is only one file involved. System A counts the File Y as an EIF.

Scenario 3

System A Update on System B Files. System B handles the file access

An update transaction initiated by System A, has as its primary intent the update of data in File Y in System B. This results in the update DETS being sent by A to System B. System B accesses File Y and updates the data. A confirmation/error message response may or may not be sent to System A. System A displays the response on a screen

Scenario 3 Resolution

Transactions

Both System A and System B contribute to the update function. Both count one EI.

Neither system counts the messaging between the two applications i.e. the sent update data and response messages.

A variation of this scenario occurs where multiple systems initiate the same EI. All initiating systems count one EI but System B counts only one EI.

Files

There is only one file involved. Both System A and System B counts the File Y as an ILF.

Scenario 4

 System A Update on System B Files. System A handles the file access

An update transaction initiated by System A, has as its primary intent the update of data in File Y in System B. System A has all the functionality required to directly access and update the File Y. System A may display error/confirmation messages on a screen

Scenario 4 Resolution

Transactions

System A has all the necessary functionality to deliver the complete update function. System A counts one EI.

There is no messaging between the two applications

Files

There is only one file involved. System A counts the File Y as an ILF. System B counts the File Y as an ILF as it is assumed that it also has a maintenance function that updates this file.

Scenario 5

System A Update on File X requires validation/contribution of data from File Y. System B handles the File Y access

An update transaction initiated by System A, has as its primary intent the update of data in File X. As part of the processing of the transaction, data from File Y in System B must be accessed for validation/contribution purposes. This results in a request for information sent by A to System B. System B accesses File Y and sends a response with the required data to System A. System A completes its processing and the File X is left in a consistent state.

Scenario 5 Resolution

Transactions

Both System A and System B contribute to the update function. System A counts an EI. System B counts an EQ

Neither system counts the messaging between the two applications i.e. the request and response messages.

Files

There two files involved. System A counts the File X as an ILF and the File Y as an EIF. System B counts the File Y as an ILF.

Scenario 6

System A Update on File X requires validation/contribution of data from File Y. System A handles the File Y access

An update transaction initiated by System A, has as its primary intent the update of data in File X. As part of the processing of the transaction, data from File Y in System B must be accessed for validation/contribution purposes. System A has all the functionality required to directly access the File Y. System A may display error/confirmation messages on a screen

Scenario 6 Resolution

Transactions

System A has all the necessary functionality to deliver the complete update function. System A counts one EI.

There is no messaging between the two applications

Files

There two files involved. System A counts the File X as an ILF and the File Y as an EIF. System B counts the File Y as an ILF as it is assumed that it also has a maintenance function which updates this file.

Scenario 7

System A Enquiry on multiple System B Files. System B handles the file access

An initial enquiry transaction (which could potentially result in multiple subsequent enquiries) is initiated by System A, and requires information from File Y and File Z in System B. This results in a request for information sent by A to System B. System B access File Y and File Z, 'gathers' all the required information to handle the initial and subsequent enquiries, and sends a response with the required data to System A. System A temporarily stores the data gathered from System B. System A displays the response data on a screen. Subsequent enquiries are satisfied by referencing the data stored in the temporary file. At the end of the Enquiry 'session' the data in the temporary file is cleared.

Scenario 7 Resolution

Transactions

Both System A and System B contribute to the enquiry functions. System B counts one EQ. System A counts multiple EQ's

Neither system counts the messaging between the two applications i.e. the request and response messages.

Files

There are three files involved. System B counts File Y and File Z as ILFs. System A counts File Y and File Z as EIFs. Neither system counts the temporary data storage file.

An exception to this situation may occur when, in counting System A, the FP Analyst has no knowledge of the files in System B. If the temporary file is the only 'view;' that System A has of System B data, this temporary file represents the EIFs and is counted.

Scenario 8

System A Update on File X triggers a subsequent update of File Y in System B. System A handles the File X access. System B handles the File Y access

An update transaction initiated by System A, has as its primary intent the update of data in File X. As a consequence of this update, data in File Y in System B is also required to be updated. Once System A completes its processing, a control transaction is sent to System B to trigger the consequent update. System B updates File Y.

Scenario 8 Resolution

Transactions

Both System A and System B count their unique EI transactions. System A counts an EO for the control transaction sent to System B.

Files

There two files involved. System A counts the File X as an ILF. System B counts the File Y as an ILF.

This scenario differs considerable from those previously described. The scenario is described in detail in Section 3.3.5, Front-end Systems - Counting Guidelines.

System A is a Front-end System that has screens available to enter update data. The ultimate purpose of the System A screens are to update data on System B files. The difference between this and the previous scenarios is that System A is required to store a copy of the transaction data sent to System B. For example, the sequence of events is as follows:

• System A has a screen that permits the user to Create an Order.
• The Order details are stored within System A in an Order Transaction File.
• At regular intervals, System A sends the Create Order Transactions to System B. At the time the order is sent the status of the transaction on the Order Transaction file is set to "Sent"
• System B receives the order details from A and initiates its own Create an Order transaction that updates the Order File in System B.
• System B sends System A a Confirmation message.
• System A receives the confirmation message and updates the status of the transaction on the Order Transaction file to "Order Created"
• At any point in time, System A users can enquire upon the Order Transaction file to determine the status of the Order.

• EI - Create an Order
• EO - Send Order Details (Transaction includes update of status to "Sent")
• EI - Receive Order Confirmation (Transaction includes update of status to "Order Created")

System B counts:

• EI - Create an Order
• EO - Send Order Confirmation