Section C Final - Attachment 9.docx

GSA SOLICITATION QMAD-JM-100001-N

Attachment 9 – Agency Business Systems Integration Guidance Notional Interface Standards August 23, 2010

GSA SOLICITATION QMAD-JM-100001-N

Attachment 9 – Agency Business Systems Integration Guidance Notional Interface Standards August 23, 2010

Attachment 9 Agency Business Systems Integration Guidance Notional Interface Standards This document includes the notional guidance for how this integration capability may be achieved, including:

1. Data communication transport modes. The data interface section provides the requirements for the exchange modes that must be supported, including:

a) File uploading and downloading between a customer agency(s) and ETS2;

b) Synchronous exchanges initiated by either a customer agency or ETS2; and

c) Asynchronous exchanges initiated by either a customer agency or ETS2.

2. Typical Interface transactions

a) Agency HR Business Systems and ETS2

b) Agency Financial Business Systems and ETS2

c) GSA SmartPay

d) MIS data transfer

Figure 1 – ETS2 Integration Diagram below describes the various components of the ETS2 capability and what services should be offered under what CLIN.

F

Figure 1: ETS2 Integration Diagram

ETS2 Integration Component

ETS2

should include an EAI Capability as required in Section C.8, and further described in

Attachment 9, and this is included in the

ETS2

Voucher Fee

Configurable Interfaces:

Do not require major development efforts, are based on configurable capabilities , and are included in Standard Implementation Services

Agency Business Systems:

Agency business systems should have the ability to offer pre existing APIs as integration points for the core interfaces necessary to exchange data with

ETS2.

Interfaces between ETS2 and Agency Business System

Customized Interfaces:

Less desirable by the government , customized interfaces are estimated and proposed to Agencies based on hourly rates from

CLIN0013

ETS2 Integration Layer

ETS2

Travel Service:

Requirements for ETS2

Travel Service components required in Section C are included in the ETS2 Voucher Fee

A. Data Communication Transport/Protocol Modes ETS2 shall provide data communication interfaces for Agency Business Systems that are within the control of the agencies that utilize ETS2. Due to the disparate nature of the business systems that are currently deployed and agency policies for integrating their applications with external systems; these data communication interfaces may range from file based data communication interfaces to synchronous data interfaces that happen as close to “real” time as is mandated by the business and is technically feasible. To accommodate the different modes required for information exchange when integrating ETS2 with Agency Business Systems, these requirements are separated based on the inherent capabilities and limitations of each of the models for communicating information between ETS2 and the Agency Business Systems. The integration modes that define the core integration needs between ETS2 and the Agency Business Systems include:

1. File Exchanges initiated by ETS2 to an Agency Business System

2. File Exchanges initiated by Agency Business Systems to ETS2

3. Synchronous message exchanges initiated by ETS2 to an Agency Business System

4. Synchronous message exchanges initiated by an Agency Business System to ETS2

5. Asynchronous message exchanges initiated by ETS2 to an Agency Business System

6. Asynchronous message exchanges initiated by an Agency Business System to ETS2

The interface effort shall be optimized for configuration versus customization for these integration modes between any Agency Business System and ETS2. This is applicable to all interface efforts. All messages exchanged between ETS2 and the agency business systems shall be NIEM (National Information Exchange Model) compliant.

Additionally all listed data communication modes support “out-of-band” communication channels. These communication channels are for controlling characteristics of the information exchanges that can vary by agency and are technically feasible to be supported. An example is uploading a new XSLT for formatting information sent from ETS2 to an Agency Business System I. File Exchanges Initiated by ETS The file exchange transfer requirements are designed to establish a flexible model for file exchanges between ETS2 and the Agency Business Systems. Additionally, this interface supports the ability for Agency Business Systems to control aspects of file creation by additional interactions that should be available.

1. ETS2 should support routine file generation and receipt/import as mandated by agencies that are interconnected to ETS2;

2. ETS2 should support producing files in formats that are required for the agencies including XML and other formats to accommodate specific receiving organizations needs;

3. ETS2 should support utilizing any of the supported element naming models that will potentially be implemented including standard data dictionary, CGAC naming if applicable and Travel Industry Standard element models;

4. ETS2 should support formatting the data elements in any higher level structures that are required by an agency such as XML files defined in a XML Schema or as part of a XSLT document provided by the agency. Creation of the specific file formats will be a joint effort and that vendor will be responsible for creation of the XML/XSLT mappings;

5. ETS2 should either place the file in a location that is accessible to the agency appropriate system for pulling or download it to the specified agency location;

6. ETS2 should support uploading of XSLT files from agencies to support XML file format alterations as needed by Agency Business Systems;

7. ETS2 should be capable of incorporating the new XSLT within the same interval as specified for minimum interval for file creation;

8. ETS2 should allow agencies to upload additional instructions to allow an agency to specify file naming for a produced file or timing of when the file creation will occur;

9. ETS2 should support agency specific file creations with less than a 24 hour turnaround;

10. ETS2 should only support creating file with data elements that are in the standard data set;

11. ETS2 should not support operations on the individual data elements that are available in the standard data set such as math functions or string manipulations. ETS2 shall only supply the data elements in their native form maintained by ETS2;

12. ETS2 should ensure that the file creation and delivery implementations ensure appropriate security such that only authorized information based on agency or external organization is received and/or,

13. ETS2 should maximize support for configuration to create file based message extracts versus customization that requires software development.

II. File Exchanges Initiated by Agency Business Systems ETS2 may receive periodic uploads of information from various Agency Business Systems including agency business applications and other organizations that maintain systems the support the business needs for travelers.

1. ETS2 should support the uploading of files from authorized Agency Business Systems;

2. ETS2 should provide the XSLT and other formatting information for structuring files in an acceptable fashion for ETS2 to perform the import operation for those files sent in XML format;

3. ETS2 should support XSLT utilizing all available data dictionaries (as defined in C.8.2) and providing the appropriate translation before insert into ETS2;

4. ETS2 should provide a staging location for imported files that is highly available accessible with appropriate security to those Agency Business Systems that will upload information;

5. ETS2 should provide a 24 hour turn-around for inserting the information into ETS2 from the staged file location;

6. ETS2 should not be responsible for format translations to import information into ETS2. All information translations will be implemented by the Agency Business Systems supplying information to ETS2;

7. ETS2 should provide a file record of all insert/update operations that were requested and the status of completion. This transaction result file will be available for download by the requesting agency;

8. ETS2 should accept in the upload request a file name for result file if the agency has requested a transaction log of the updating operations;

9. ETS2 should maximize support for configuration to create file based information imports specify what options are solely implementation capable by software development;

10. ETS2 should support Agency Business Systems specifying the information insert operation time as part of the uploaded information set;

11. ETS2 should accommodate uploading any data elements that are agency writeable information using the file upload interface mode;

12. ETS2 should maximize support for configuration to create file based message extracts versus customization that requires software development and/or,

13. ETS2 should not support operations on the individual data elements that are available in the standard data set such as math functions or string manipulations. ETS2 should only supply the data elements in their native form maintained by ETS2.

III. Synchronous Message Exchanges initiated by ETS2 ETS2 may provide outgoing information and updates to information utilizing synchronous communication in support of those information exchanges enumerated in the Data Exchange section.

1. ETS2 should support synchronous message exchanges for multiple business purposes including but not limited to:

a) Obligations and Travel Advance Payments

b) Accounting String Verification

c) Funds Available

2. ETS2 should format the message using agency specific formatting standards including agency XML tags

3. ETS2 should support with restrictions the ability to alter the XML tagging and other data element demarcations

4. ETS2 should be able to receive message responses from Agency Business Systems using agency specific formatting standards including XML tags

5. Message return from agency should occur as a response to the initiated message utilizing the same communication mechanisms such as SOAP, Java RPC, etc.

6. ETS2 should not be required to support synchronous incoming information utilizing inherently asynchronous exchange models such as MQ or JMS

7. ETS2 should support an out-of-bound communication channel for control information sent by the agency. This information potentially will include:

a) Connection Bind Information

b) Message Formatting & Translation Information

8. ETS2 should be capable of utilizing an “out-of-bound” control channel if offered by the agency for control information sent from ETS2 to the agency

IV. Synchronous Message Exchanges initiated by Agency Business Systems ETS2 may receive incoming information and updates to information utilizing synchronous communication in support of those information exchanges enumerated in the Data Exchange section.

1. ETS2 should support a message exchange that queries and updates appropriate information maintained within ETS2;

a) Information sent to ETS2 should be native data dictionary compliant

b) Return should occur as a response to the initiated message utilizing the same communication mechanisms such as SOAP/WS-I Basic Profile 1.2 specifications, Java RPC, etc.

c) The ETS2 response should be standardized by the ETS2 vendor

d) ETS2 should format operation results to match agency format if formatting standards are supplied by the agency

e) The agency is responsible for creating and maintaining any translation information

2. ETS2 should only support synchronous updating of information from the data dictionary that is agency controlled information such as accounting strings. This is restricted to ETS2 static information;

3. ETS2 should not support this mode for large information extracts;

4. ETS2 should not support state-full multi-exchange transactional communication

5. ETS2 should support synchronous communication paradigms for these operations such as;

a) Native Sockets

b) Client/Server Such as WS-I, DCE RPC, Java RMI

6. ETS2 should not be required to support synchronous incoming information utilizing inherently asynchronous exchange models such as MQ or JMS;

7. ETS2 should support an out-of-bound communication channel for control information sent by the agency. This information potentially may include:

a) Connection Bind Information

b) Message Formatting & Translation Information

8. ETS2 should be capable of utilizing an “out-of-bound” control channel if offered by the agency for control information sent from ETS2 to the agency.

V. Asynchronous Message Exchanges initiated by ETS2 ETS2 may provide outgoing information and updates to information utilizing asynchronous communication in support of those information exchanges enumerated in the Data Exchange section. This is expected in a fashion similar to that used for synchronous messages sent to Agency Business Systems.

1. ETS2 should support outbound asynchronous messages utilizing mandated agency communication message oriented transport protocols

2. ETS2 should support all requirements that are enumerated for synchronous outbound message exchanges

VI. Asynchronous Message Exchanges initiated by Agency Business Systems ETS2 may receive incoming information and updates to information utilizing asynchronous communication in support of those information exchanges enumerated in the Data Exchange section. This is expected in a fashion similar to that used for synchronous messages sent to ETS2.

1. ETS2 should support incoming asynchronous messages utilizing mandated agency communication message oriented transport protocols; and,

2. ETS2 should support all requirements that are enumerated for synchronous incoming message exchanges.

B. Typical Interface tRANSactions

I. AGENCY HUMAN RESOURCES BUSINESS SYSTEM (HR) AND ETS2 INTEGRATION

1. Initial Load: Bulk load of all existing employee records into the ETS2 system from the Agency HR System

2. New Employee: As an employee is entered into the Agency HR System, the employee record shall be delivered to ETS2, which shall process the data to create the traveler’s profile.

3. Update Employee: As an employee is updated in the Agency HR System, the employee record shall be delivered to ETS2, which shall process the data to update the traveler’s profile.

4. Deactivate Employee: As an employee is terminated in the Agency HR System, the employee record shall be delivered to ETS2, which shall process the data to deactivate the traveler’s profile.

II. Agency Financial Business System and ETS2 integration

1. Creation of Travel Authorization: Upon approval of a travel authorization, agencies will obligate the estimated trip expenses. As a travel authorization is created in ETS2 and approved, the standard data elements pertaining to the travel authorization shall be interfaced to the Agency Business System, which shall process the data to create the obligation of funds.

2. Cash Advance: Travel cash advances are generally limited to those employees who travel infrequently (less than once each twelve months), and to employees who are not eligible for a government credit card. Cash advances will be disbursed through the agency. If a travel authorization has an associated advance, key data pertaining to advance shall be interfaced to Agency Business System, which shall process the data to create an advance record.

3. Modification/Amendment of Travel Authorization: When a travel authorization is modified/amended after approval, it is necessary to adjust the obligation for travel that has been booked to the Agency Business System. Travel authorizations may be amended for a variety of factors that pertain to the transaction, including: a change in estimated trip amounts, payment methods, accounting distributions or additional cash advance requests. As an approved and interfaced travel authorization is modified in ETS2 and approved, the standard data elements pertaining to the travel authorization shall be interfaced to the Agency Business System, which shall process the data to modify the obligation of funds.

4. Cancellation of Travel Authorizations: As an approved and interfaced travel authorization is modified in ETS2, the standard data elements pertaining to the travel authorization shall be interfaced to the Agency Business System, which shall process the data to cancel the obligation of funds.

5. Partial voucher: To properly manage the obligation liquidation upon approval of the travel voucher, it is important to know whether the voucher is “final” (the traveler will not submit additional travel vouchers) or a partial travel voucher. When a final voucher is indicated, the entire travel obligation is liquidated. If not, only the amounts on the travel voucher will be de-obligated. Remaining amounts will continue to be available to the traveler for subsequent trips. As a voucher is created in ETS2 and approved, and the voucher is not marked as the final voucher in ETS2, the standard data set for a voucher shall be interfaced to the Agency Business System, including cross-reference to the existing obligation.

6. Final voucher: As a voucher is created in ETS2 and approved, and the voucher is marked as the final voucher in ETS2, the standard data set for a voucher shall be interfaced to the Agency Business System, and an indicator for the final voucher shall be included. The agency business system shall close the associated obligation and any associated advances.

7. Voucher without Authorization: In some cases (like local vouchers); agencies may not require travel authorizations. In these instances, it is necessary to prepare a travel voucher that is not associated to a pre-existing travel authorization. While the vouchers prepared for these trips require the same data as a trip that is sourced from a travel authorization, there is no obligation to liquidate. As a voucher without authorization is created in ETS2 and approved, the standard data set for a voucher shall be interfaced to the Agency Business System, without obligation cross reference, and the Agency Business System shall process the non-obligated vouchers.

8. Fund Checking: ETS2 shall perform funds checking by passing the amount and the account code to the Agency Business System. The Agency Business System shall respond with one of three options: funds available, and advisory warning, or an absolute error, as required by the agency.

9. Outstanding Advances: In the situation where the final voucher total is less than the outstanding advance associated with the authorization, the Agency Business System shall identify outstanding authorized advance amounts – these typically would not be handled by an ETS2 interface.

10. Open Authorizations: Federal agencies may create authorizations that are specific to a single traveler for a longer period of time or specific amount of funds. These authorizations can be accounted for in many ways and shall be handled the manner preferred by the agency. Typically, the system will obligate the estimated amount when the open authorization is approved, and not obligate any amounts when individual travel authorizations are sourced from the open authorization. Travel Vouchers will liquidate the appropriate portion of the obligation for the open authorization.

11. Accounting Codes: In order to successfully record travel transactions in an agency financial system, it is essential to capture each of the agency’s accounting elements and pass only valid combinations of these elements. Some agencies may be able to narrow the population of financial data to include only those elements that may be used for travel transactions. Accounting code interfaces can generally be described as:

a) Bulk Load accounting strings: The agency can identify all completed accounting strings (or designated shortcuts) that may be used for travel expenses, and identify a regular load/update of the current accounting strings available for travel. In an agency designated frequency, these accounting strings shall be delivered to ETS2, which shall process the data to create a selectable list of strings as determined by agency configuration.

b) Bulk Load accounting elements: In situations where the optional use of Dynamic Accounting is provided, the agency shall identify the accounting string elements available for travel. In an agency designated frequency, these accounting strings shall be delivered to ETS2, which shall process the data to create a dynamically selectable set of elements available to the traveler to build accounting strings as configured by the agency

c) Accounting Code validation: If desired, the agency can request the ability to verify the usability of the accounting code, to eliminate errors.