1. Integration Framework Pennsylvania Treasury
for
PeopleSoft at
Pennsylvania Treasury

2. What is Integration Framework for PeopleSoft (IFP)?
The Integration Framework for PeopleSoft is a bolt-on that leverages Pure Internet Architecture, Integration Broker, object-oriented PeopleCode, and other PeopleSoft technologies to provide an enterprise-grade integration solution without the need for middleware or third-party software. IFP provides an Application Programming Interface that is a standards-based environment for developing high-performance PeopleSoft interfaces supporting both web service and file integration points utilizing common business logic. IFP interface templates facilitate rapid interface development while enforcing best practices. IFP includes tools for configuring and managing interfaces, client self-service utilities, and an inventory of pre-developed interfaces.

3. Why did Pennsylvania Treasury chose IFP?
The Pennsylvania Treasury is responsible for all disbursement of funds for the Commonwealth of Pennsylvania including payroll, pension, welfare, and vendor payments. Each year Treasury processes over 30 million requests for payment from more than 30 agencies. Treasury’s mission is to ensure every payment is accurate and timely.
To perform their mission Treasury required an integration solution that could ensure data integrity by performing hundreds of validations while scaling to very high volumes. They also needed an adaptable solution that could accommodate the diverse technology and business process requirements of more than two dozen agencies. Finally, the solution had to be cost-effective to implement and support.
By selecting IFP for its integration solution, Treasury was able achieve its goals. Because IFP leverages native PeopleSoft infrastructure and technology, no additional investment in hardware, software, or training was required. IFP provided an API for rapid interface development, support for both web service and traditional file technologies, configurability to adapt to agency business processes, and utilities to facilitate support.

4. Did IFP meet Treasury’s expectations?

5. Integration Architecture
Agency accesses an IFP web service which instantiates an interface IFP Message Handler.
IFP File Broker scans for inbound files and publishes a FileUploadNotification message to initiate processing. The FileUploadNotification message handler determines from interface configuration whether to process the file or hand it off to the process scheduler. The IFP File Handler is instantiated to process the file.
GlobalScape transports interface files between treasury and agency systems.

6. Features & Functionality

7. Uniform Interface Document Structure
Header – contains routing and control information.
Data Module – contains one transaction. There can be multiple transactions per interface document.

8. Standard Acknowledgement
Header – contains routing and control information.
Data Module – contains transaction validation messages.

9. Interface Document Definition – XML
Web Service and XML File documents are defined using Integration Broker messages.
Extended Message Definitions map part messages to interface document parts.

10. Interface Document Definition – Flat Files
Flat File interface documents are defined using multiple Application Designer File Layout Definitions Extended Layout Definitions map file layout definitions to interface document parts.

11. Interface Templates
IFP and IFP-compliant interfaces are built on the Enhancement Framework for PeopleSoft (EFP). EFP-provided support functionality includes: temporary instance management, ad hoc parameters, documentation repository, trigger management, configuration templates, extensible API classes, and custom page controls.

12. Interface Configuration – Node-Specific File Schemas
This interface supports multiple response document schemas. Version v1 is the default.
This agency receives response document schema version v2.

13. Interface Configuration – File Processing Options
Transmission of a response document (acknowledgement) can be suppressed via configuration.
Interface file processing can occur on either the Application Server or Process Scheduler Server.
Schema validation is selectable.

14. Interface Configuration – Error Handling & Post-Processing
The Payment Request interface can be configured to reject only invalid requests or all requests when errors are found in a document.
The Payment Request interface can be configured to automatically schedule a customized version of voucher build for execution.

15. Email Notifications Email notifications are event driven.
Global Notifications apply to all interfaces for all nodes.
Processing exception notifications are sent to Treasury support staff.
Node Notifications apply to all interfaces for a specified node.
Acknowledgements are sent to agency staff.
Node/Interface Notifications apply to a specified interface for a node.
Data rejection notifications are sent to agency staff.

16. Email Notification Templates
Customizable notification templates.
Replacement variables.

17. Web Service Integration Point – Inbound Data
Request Message
Response Message
(Standard Acknowledgement)

18. Web Service Integration Point – Outbound Data
Request Message
Response Message

19. File Integration Point – Inbound Data
Request File
Response File
(Standard Acknowledgement)

20. File Integration Point - Outbound Data, Push Mode
Request file is simulated by the Schedule Requests process.
Replacement variables can be used in the run control parameters to create dynamic run controls.
Response File

21. Integration Monitor – File Example
Hyperlink to view archived request file
Hyperlink to view archived response file
Control Counts

22. Integration Monitor – Web Service Example
Hyperlink to view Integration Broker details
Control Counts

23. Client Self-Service Utilities – Interface Schema Viewer
The Interface Schema Viewer can be used during client interface development to obtain the web service WSDL URL and to view interface XSD.

24. Client Self-Service Utilities – File Validator
The Interface File Validator can be used during client unit testing to validate file structure and data content without reliance upon IFP user staff. Request files can be uploaded from client workstations. The validator provides feedback in the interface response message format.

25. Client Self-Service Utilities – Outbound Interface File Generator
The Outbound Interface File Generator can be used during client unit testing to obtain sample interface files. Request file text is pasted into the XML window and the generator creates an outbound interface file that can be downloaded to a client workstation.

26. Technology
IFP requires no specialized hardware, software, or skills sets. It provides a robust integration solution by leveraging the native capabilities of PeopleSoft Pure Internet Architecture (PIA), Integration Broker, PeopleTools, and object-oriented PeopleCode.

27. Object-Oriented PeopleCode
Application Class interface templates provide consistent structure and expedite interface development.
Use of object-oriented PeopleCode facilitates rapid application development and provides extensibility while maintaining upgradeability.

28. Common Business Logic
Supports traditional flat file integration points utilizing simple File Adapters.
Supports Service Oriented Architecture (SOA) web service integration points via easy-to-build XML Adapters.
All interface transformation, validation, and loading logic resides in the Interface Engine.

29. InSync Set-Based Interface Template Processing Flow

30. InSync Set-Based Interface Template Processing Flow
Seq #
Detail
10S
A Payment Request arriving via the web service integration point as an XML message will be transformed by the interface implementation of the IFP Template Message Handler Class into a rowset data object and passed to the interface engine class implementation.
10F
A Payment Request arriving via the file integration point as an XML-formatted file will be transformed by the interface implementation of the IFP Template File Handler Class into a rowset data object and passed to the interface engine class implementation. 20
The Engine Class stages payment request data into interface processing tables. 30
The Prepare Data section of the interface implementation of a VTL Application Engine is called by the Engine Class to set default values and prepare staged data for validation. 40
The Validate Data section of the interface implementation of a VTL Application Engine is called by the Engine Class to perform interface edits. 50
The Transform Data section of the interface implementation of a VTL Application Engine is called by the Engine Class to set prepare valid staged data for loading into voucher build staging tables. 60
The Load Data section of the interface implementation of a VTL Application Engine is called by the Engine Class to load data into the voucher build staging tables. 70
The Delete Data section of the interface implementation of a VTL Application Engine is called by the Engine Class to delete interfaced data from the interface processing tables. 80
The Engine Class schedules the voucher build batch process, AP_VCHRBLD, if configured.
90S
The Message Class converts interface edit messages to the IFP Acknowledgement XML Message structure and returns it to the source system.
90F
The File Class writes interface edit messages to an IFP Acknowledgement file for GlobalScape to route to the source system.