CS HCM Integration Person BioDemo Guide 05-31-2011

PeopleSoft Integration Reference Guide
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
May 2011
Including: Overview of Campus Solutions 9.0 to HCM Integrations Step-by-Step of Implementation Activities Troubleshooting Tips and Techniques
PeopleSoft CS to HCM
Copyright 2010 Oracle, Inc. All rights reserved. Printed on Recycled Paper. Printed in the United States of America. Restricted Rights The information contained in this document is proprietary and confidential to PeopleSoft, Inc. Comments on this document can be submitted to Global Support Center. We encourage you provide feedback on this Integration Guide and will ensure that it is updated based on feedback received. When you send information to Oracle, you grant Oracle a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Oracle. This document is subject to change without notice, and Oracle does not warrant that the material contained in this document is error-free. If you find any problems with this document, please report them to PeopleSoft in writing. This material has not been submitted to any formal Oracle test and is published AS IS. It has not been the subject of rigorous review. Oracle assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by Oracle for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk Information in this book was developed in conjunction with use of the product specified, and is limited in application to those specific hardware and software products and levels. Oracles may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. PeopleSoft, PeopleTools, PS/nVision, PeopleCode, PeopleBooks, PeopleTalk, and Vantive are registered trademarks, and Pure Internet Architecture, Intelligent Context Manager, and The Real-Time Enterprise are trademarks of Oracle. All other company and product names may be trademarks of their respective owners. The information contained herein is subject to change without notice.
TABLE OF CONTENTS
Table of Contents Chapter 1 - Introduction Structure of this Document Related Materials Chapter 2 - Overview Introduction Who Should Read This Guide? Before You Begin Common Terms Chapter 3: Configuring and Administering PeopleSoft CS to HCM Integrations Understanding PeopleSoft CS to HCM Person Bio-Demo Data Integrations Loading the Setup Data Configuring and Administering CS HCM Person Bio-Demo Data integrations Chapter 4: Understanding Business Process Impacts in owner/subscriber integration Configuring the Last Employee ID Assigned Number APPENDIX A CONFIGURING INTEGRATION BROKER GATEWAYS AND NODES APPENDIX B - CONFIGURING FULLSYNC SERVICE OPERATIONS APPENDIX C FULLSYNC AND SYNC SERVICE OPERATIONS INCLUDED FIELDS APPENDIX D BATCH PUBLISH DESIGN PATTERN Developer Activities Tips and Techniques Frequently Asked Questions APPENDIX E INTEGRATION BROKER TROUBLESHOOTING Integration Broker Troubleshooting APPENDIX F VALIDATION AND FEEDBACK Customer Validation Field Validation APPENDIX G REVISION HISTORY Authors Revision History 3 4 4 4 5 5 5 5 6 7 7 8 14 31 35 36 41 55 110 114 128 129 131 131 135 135 135 136 136 136
Copyright Oracle USA 2010. All rights reserved.
Page 3 of 136
CHAPTER 1 - INTRODUCTION
This Integration Guide is a practical guide for functional and technical users, installers, system administrators, and programmers who implement, maintain, or develop applications for your PeopleSoft system. In this Integration Guide, we discuss Person bio-demo data integrations between CS and HCM. This includes configuring and troubleshooting a PeopleSoft Integration Broker environment. .
Structure of this Document

This document provides guidance for the implementation of CS to HCM Integrations. It outlines the scope and configuration steps of objects available to support CS HCM integrations. Keep in mind that Oracle updates this document as needed so that it reflects the most current feedback we receive from the field. Therefore, the structure, headings, content, and length of this document is likely to vary with each posted version. To see if the document has been updated since you last downloaded it, compare the date of your version to the date of the version posted on My Oracle Support.
Related Materials
We recommend that before you read this guide, you also read the Campus Solutions-HCM Integration White Paper; it provides an overall summary of the objectives and various approaches to supporting separate CS and HCM instances. In addition to this document, additional implementation guides have been developed to assist you in understanding and implementing your CS HCM integrations. These documents and the Campus Solutions-HCM Integration White Paper are posted to My Oracle Support, associated with Feature Pack 4 Documentation (ID 1259484.1 ). Implementing Person Bio-Demo Data Integration between CS and HCM on My Oracle Support Implementing External Search/Match between CS and HCM on My Oracle Support Implementing CS Integration with the Higher Education Constituent Hub on My Oracle Support (Note that this document will not be released until late 2010 or early 2011) Implementing Portal Navigation Aggregation for CS and HCM Integration on My Oracle Support
This document is not a general introduction to Integration Broker and we assume that our readers are experienced IT professionals, with a good understanding of PeopleSofts Internet Architecture. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of system administration, basic Internet architecture, integration technologies, relational database concepts/SQL, and how to use PeopleSoft applications. This document is not intended to replace the documentation delivered with the PeopleTools 84x or 8.5x PeopleBooks. We recommend that before you read this document, you also read the PIA related information in the PeopleTools PeopleBooks to ensure that you have a well-rounded understanding of our PIA technology. Note: Much of the information in this document eventually gets incorporated into subsequent versions of the PeopleBooks. Many of the fundamental concepts related to PIA are discussed in the following PeopleSoft PeopleBooks: PeopleSoft Internet Architecture Administration (PeopleTools|Administration Tools|PeopleSoft Internet Architecture Administration) Application Designer (Development Tools|Application Designer) Application Messaging (Integration Tools|Application Messaging) PeopleCode (Development Tools|PeopleCode Reference) PeopleSoft Installation and Administration PeopleSoft Hardware and Software Requirements
Page 4 of 136
CHAPTER 2 - OVERVIEW
This chapter includes the following topics: Introduction Who Should Read This Guide? Before You Begin Common Terms
Introduction
The Campus Solutions suite of products has historically resided in a single database instance with HCM. This coupling has enabled CS and HCM to share a person model, a single instance of a person in the system, and student refund processing through HR Payroll. Oracle is supporting a set of integrations (asynchronous fullsync and incremental sync) that will keep many of these core Person bio-demo data values synchronized between your separate CS and HCM systems. Fullsync requires user intervention to initiate the process for each table. Incremental sync uses services that are triggered by PeopleCode in the online components when data changes. The list of available integrations for person bio-demo data is detailed later in this document. You will want to understand, and determine, which of the service operations you will need to enable with your CS HCM integrations.
Who Should Read This Guide?

Typically, administrative users configure and administer the application. An administrative user can be either an Oracle Consulting Services representative or the designated members of your implementation team who are familiar with Integration Broker and your organizations business process requirements. Functional users with a good understanding of core CS Campus Community and Human Resources functionality and business processes will be an essential part of your implementation. This guide assumes at least that level of knowledge and describes how to implement PeopleSoft Enterprise Campus Solutions HCM Person Bio-Demo Data Integrations.
Before You Begin

Before you can setup, administer, or use PeopleSoft Campus Solutions - HCM integrations, you must install or upgrade the HCM 9.0 / 9.1 environment and then set up / configure the Integration Broker between the two applications for your institution. The steps detailing the installation or upgrade of your HCM 9.0/9.1 system are not part of the scope of this document.
Page 5 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Some examples of the configuration tasks that you must perform for your CS to HCM Integrations include: Configuring the PeopleSoft CS and HCM installation and PeopleTools options tables. Setting up the integration gateway and integration nodes within the Integration Broker system. Activating services, service operations, and routings within the Integration Broker system. Defining roles and permissions for your user profiles.
Common Terms
This table provides definitions for some of the common terms that are used in this guide. Term CS HCM EIP Campus Solutions product suite. Human Capital Management product suite. Enterprise Integration Point. These include Fullsync and incremental Sync service operations. Another term for System of Record; the system that publishes data to a subscribing system in synchronization services. System of Record; the system that publishes data to a subscribing system in synchronization services data loads. User profiles define individual PeopleSoft users. You define user profiles and then link them to one or more roles. Typically, a user profile must be linked to at least one role to be a usable profile. The majority of the permissions that make up a user profile are inherited from the linked roles. Definition
Owner
SOR
User Profiles
Page 6 of 136
CHAPTER 3: CONFIGURING AND ADMINISTERING PEOPLESOFT CS TO HCM INTEGRATIONS

This chapter discusses how to configure and administer Integrations for your system. It provides an overview of the Integration Broker system and discusses the following topics: Configuring the PeopleSoft CS and HCM installation and PeopleTools options tables. Setting up the integration gateway and integration nodes within the Integration Broker system. Activating services, service operations, and routings within the Integration Broker system. Defining roles and permissions for your user profiles
Understanding PeopleSoft CS to HCM Person Bio-Demo Data Integrations

For PeopleSoft CS - HCM integrations, you must configure both systems and then load data from your system of record to your subscribing target system before you configure additional application features and deploy the application from your website to the intended users. Determine your system of record (owner) for this data by fully evaluating the business processes and data ownership practices at your institution. You may determine that revised process and data governance policies may be beneficial as you implement separate CS and HCM systems. The details in this guide describe the configurations necessary for the following integration models: Owner/Subscriber implementation, where CS 9.0 is the system of record for Person information, and HCM 9.1 is the subscribing target system. Subscriber Only, where both CS 9.0 and HCM 9.0/9.1 is a shared system of record for Person information. Both systems are defined as subscribing target system.
Owner/Subscriber For customers implementing an Owner/Subscriber integration model, Oracle recommends a best practice of establishing your CS system as the system of record for personal data, with your HCM system as the subscribing target. The HCM system is the system of record for required HCM data, including basic HR Workforce Administration setup data and Workforce transactional data. Subscriber Only Customers implementing the Subscriber Only integration model will allow personal data to be added and updated in both CS and HCM systems. The HCM system will remain as the system of record for required HCM data, including basic HR Workforce Administration setup data and Workforce transactional data.
Administrative Tasks for CS HCM Person Bio-Demo Data Integrations

This section lists the high-level administrative tasks that you must complete to enable your CS HCM personal data integrations. The following table lists the required tasks, the tool required to complete each task, and additional instructional notes.
Page 7 of 136
Task Configure Integration Broker messaging
Phase Implementation
System CS 9.0 HCM 9.0/9.1
Tool Required Integration Broker
Comments Configure remote gateway. Add integration nodes for Integration Broker environment. Configure FullSync and Sync Setup Data service integrations.
Run full synch setup data messaging
Implementation
CS 9.0 HCM 9.0/9.1
Enterprise Component Full Data Publish
Assumes that Integration Broker is fully configured. For all owner/subscriber configurations, Setup data values should be populated in your subscribing target database before any person transactional data syncs are run. This is to ensure data integrity. Assumes that Integration Broker is fully configured. Fullsync data loads should follow the Transactional Data Loading Sequence as defined later in this document. In event of data errors, use online pages, reports, and queries to validate the data. Rerun full synch process as necessary.
Run full synch transaction data messaging
Implementation
CS 9.0 HCM 9.0/9.1
Enterprise Component Full Data Publish
Validate data load in Integration Broker environment
Implementation
CS 9.0 or HCM 9.0/9.1
Online access or online query Online access
Configure Portal Navigations
Implementation
CS 9.0 or HCM 9.0/9.1
See the Implementing Portal Navigation aggregation for CS and HCM Integration guide (on My Oracle Support). Provide navigation links to system of record for users to add or update data.
Configure Permissions
Implementation
CS 9.0 or HCM 9.0/9.1
Online access
Per the Implementing Portal Navigation aggregation for CS and HCM Integration guide (on My Oracle Support), and PeopleBooks. Limit, or provide display-only access to setup data pages in the subscriber system. (Users should not be allowed to update data directly in a subscribing target system, if the data is kept synchronized using integrations).
Ongoing data sync (updates)
Sustaining Support
CS 9.0 or HCM 9.0/9.1
Integration Broker
Assumes that Integration Broker is fully configured for Sync services, publishing from system of record to subscribing target system.
Loading the Setup Data

Your CS and HCM systems are integrated to enable setup data to flow between the two environments. The integration is based on Integration Broker Asynchronous Service Operations. After your system is installed, you must load the transaction data to use.
Page 8 of 136
Note. For these setup data integrations, the data flow is one way only from your system of record to your subscribing target. To maintain data integrity in this one-way flow, much of the data loaded from your owner system should be hidden from view or made display-only in the subscribing target system. See the Implementing Portal Navigation between CS and HCM guide available on My Oracle Support for more details. You can use the following methods to load data from your system of record to the subscribing target system: Full Synchronization Services (full sync initial load only) Incremental Synchronization Services (sync)
No matter what method you use, you must load data in the proper sequence to accommodate data dependencies. The following section gives a high-level description of each method and provides the required table loading sequences.
Full S ynchronization
A full synchronization service (full sync) captures all of the data that you specify in the system of record (SOR) and publishes it to the subscribing system. It first deletes all data of the specified type that is in the subscriber and replaces it with the captured data. Warning! Because of the data deletion associated with full sync, consider running full sync only at implementation time or if you must clear your CS to HCM system and begin again. Use the full sync process for data that infrequently changes.
Defining Integration Definitions

Load data from your system of record to your subscribing target system for implementation using the full sync method. To use full sync, first define full data publish rules. Then define run controls to schedule and run the full sync service for each rule. Use integration definitions pages in Enterprise Components to enable full sync data publishing. On the Full Data Publish Rules page, identify each message structure to use as a service and any chunking rules. Chunking rules allow data to be broken into more manageable pieces for tables with many rows. If you want to define a subset of data to publish, use the Record Mapping page. For example, if you are implementing only one subsidiary of your organization in CS to HCM Integrations, you might create a view that isolates that data, and then that view to map to a record contained within the service structure. On the Languages page, identify whether you want to send base language content, all related language content, or specified languages to CS to HCM Integrations. Initiate the full sync service for each table on the Full Data Publish page using the appropriate table loading sequence.
For more information on full data publishing rules or any of the Enterprise Component pages described in this section, see PeopleSoft Enterprise Components PeopleBook for PeopleSoft Enterprise HRMS & Campus Solutions, Assigning Publishing Rules.
Setup Data Loading Sequence

Minimum setup information must be available and loaded from your HCM system to your CS 9.0 system for implementation. This should be completed before any transactional data syncs are performed. The values defined in these setup tables are key to person bio-demo data integrity. Oracle recommends that your setup tables be mastered in the HCM instance. Table 1 below lists the available service operations and applicable tables. These should be loaded in order as specified into your subscribing target system.
Page 9 of 136
Integration Description Country Codes Currency Codes State/Province Codes SetIDs Tableset Controls
Integration Name COUNTRY_FULLSYNC CURRENCY_FULLSYNC STATE_FULLSYNC SETID_INITIALIZE TBLSET_CONTROL_INITIALIZE
Table(s) COUNTRY_TBL CURRENCY_CD_TBL STATE_TBL SETID_TBL SET_CNTRL_TBL SET_CNTRL_GROUP SET_CNTRL_REC REG_REGION_TBL BUS_UNIT_TBL_HR COMPANY_TBL LOCATION_TBL DEPT_TBL JOBCODE_TBL HOLIDAY_TBL HOLIDAY_DATE NID_TYPE_TBL NAME_TYPE_TBL NAME_PREFIX_TBL NAME_SUFFIX_TBL NM_ROYPREF_TBL NM_ROYSUFF_TBL TITLE_TBL ADDRESS_TYP_TBL POI_TYPE_TBL ETHNIC_GROUP_TBL US_SOC_TBL SUPPORT_DOC_TBL VISA_PERMIT_TBL, VISA_PERMIT_SUP MAJOR_TBL
Regulatory Regions HR Business Units Company Codes Location Codes Department Codes Job Codes Holiday Date Schedules National ID Types Name Types Name Prefixes Name Suffixes Name Royal Prefixes Name Royal Suffixes Name Titles Address Types Person of Interest Types Ethnic Group Codes US Standard Occupational Codes (USA) Supporting Documents (Visa/Permits) Visa Permit Types Major Codes Table 1 Setup Data Integrations
REGULATORY_REGION_FULLSYNC BUS_UNIT_HR_FULLSYNC COMPANY_FULLSYNC LOCATION_FULLSYNC DEPT_FULLSYNC JOBCODE_FULLSYNC HOLIDAY_DATE_FULLSYNC NID_TYPE_FULLSYNC NAME_TYPE_FULLSYNC NAME_PREFIX_SUFFIX_FULLSYNC1 NAME_PREFIX_SUFFIX_FULLSYNC2 NAME_PREFIX_SUFFIX_FULLSYNC3 NAME_PREFIX_SUFFIX_FULLSYNC4 TITLE_FULLSYNC ADDRESS_TYPE_FULLSYNC POI_TYPE_TBL_FULLSYNC ETHNIC_GRP_FULLSYNC US_SOC_FULLSYNC SUPPORT_DOC_FULLSYNC VISA_PERMIT_FULLSYNC COMPETENCY_FULLSYNC3
Page 10 of 136
For more information, see the Implementing Integration of Setup Data between CS and HCM guide available on My Oracle Support. This document references the configuration and execution steps for using the delivered services to keep setup data in sync.
Incremental S ynchronization
Data in the supporting tables in your system of record may change over time after the initial loading of setup, transactional data, and security data. Use incremental sync (Sync) services to send this information from your system of record to your subscribing target system to maintain data integrity. An incremental sync captures data that was created, added, changed, or deleted in the system of record since the last synchronization. It uses the captured data to overwrite the same data in the subscribing system, thereby refreshing the subscribing system so that both systems have the same data. After the initial Fullsync data loads have completed in your subscribing target system, you may inactivate the associated FullSync services, and then activate the appropriate incremental Sync services to keep your systems updated.
Manual Entry Data Load

You can, if necessary, type data manually into your CS 9.0 and HCM 9.0/9.1 systems, however it would be tedious, time consuming, and possibly introduce typographical errors. Oracle does not recommend this method for most data elements unless required to load a small amount of data.
Transactional Data Loading Sequence

For all owner/subscriber configurations, person transactional information must be available and loaded from your system of record to your subscribing system for implementation. Oracle recommends your CS 9.0 system be the system of record for Person data; your HCM system should remain the system of record for all HCM Workforce and other HR related transactional data. Note: Carefully plan your requirements for the initial load of transaction data for your specific implementation. If you are doing a new install of HCM, you will need to load this transaction data as part of your implementation. Customers upgrading to HCM 9.1 from a combined HCM and CS 9.0 database will already have the proper transaction data in place in both systems. The following table lists the required integration, indicates the type of service recommended, and the order in which you must load transactional table data into your HCM system.
Page 11 of 136
Person Transaction Data Campus Solutions 9.0 to HCM
Integration Name PERSON_BASIC_FULLSYNC.VERSION_4
HCM Table PERSON PERS_DATA_EFFDT PERS_DATA_USF* PERS_NID NAMES ADDRESSES EMAIL_ADDRESSES PERSONAL_PHONE PERS_SMOKER* PERSON_BRA* PERS_DATA_BRA* PERS_DATA_CAN PERS_DATA_CHE* PLACE_ORIG_CHE* PERS_HUKOU_CHN* PERS_DATA_DEU* NATIONALITY_GER* PERS_DATA_ESP* PERSON_FRA* PERS_DATA_FRA* PERS_DATA_IND* PERS_DATA_ITA* PERS_DATA_JPN* PERS_DATA_MEX* PERS_DATA_USA PERS_DATA_FPS* PERSON_SA
*Existing CS functionality does not populate these tables. Depending on your use of HCM functionality, the records marked with an asterisk may not have data present at the time the Fullsync is published. PERS_POI_FULLSYNC.VERSION_1 PER_POI_TYPE PER_POI_SCRTY PER_POI_SCR_DT PER_POI_TRANS DISABILITY ACCOM_REQUEST DISABILITY_FRA* DISABILITY_GER* DISABILITY_CHE* DISABILITY_ESP* DISABILITY_BRA* DISABILITY_NLD* DISABILITY_NZL*
PERSON_DISABILITY_FULLSYNC.VERSION_2
Page 12 of 136
Integration Name
HCM Table *Existing CS functionality does not populate these tables. Depending on your use of HCM functionality, the records marked with an asterisk may not have data present at the time the Fullsync is published.
PERSON_DIVERSITY_FULLSYNC.VERSION_2
DIVERSITY DIVERS_ETHNIC DIVERS_RELIGION* *Existing CS functionality does not populate these tables. Depending on your use of HCM functionality, the records marked with an asterisk may not have data present at the time the Fullsync is published.
PERSON_VISA_CITIZEN_FULLSYNC1.VERSION_1 PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1
CITIZENSHIP CITIZEN_PSSPRT VISA_PMT_DATA VISA_PMT_SUPPRT
Workforce Data HCM to Campus Solutions 9.0 Your HCM system is the system of record for managing all employee job, benefits, and payroll records. Therefore, all Job related transactional data should be maintained in your HCM system. There are times, however, when Campus Solutions must be able to access and use certain workforce related data, such as identifying when an individual is a current employee. Use the WORKFORCE_FULLSYNC service operation to initially populate, or refresh, your CS instance with this information. WORKFORCE_FULLSYNC.VERSION_3 PER_ORG_ASGN PER_ORG_INST JOB JOB_JR COMPENSATION JOB_EARNS_DIST JOB_AUS JOB_IND JOB_MIL JOB_USF HR_EE_SNR_DATES BEN_PROG_PARTIC PER_ORG_ASG_BEL PERS_REGIST_BEL PER_ORG_ASG_MIL PER_ORG_ASG_BRA PER_ORG_ASG_HP HP_EMPLT_TEACH PER_ORG_ASG_JPN PER_ORG_ASG_FA PER_ORG_ASG_NLD
Page 13 of 136
Configuring and Administering CS HCM Person Bio-Demo Data integrations

FullS ync and S ync Service Operations and Handlers
The following table summarizes the FullSync and Sync Service Operations, and Subscription Handler that you should use to configure your CS HCM person bio-demo data integrations.
Service Name PERS_POI_FULLSYNC.VERSION_1 PERS_POI_SYNC.VERSION_1 PERSON_BASIC_FULLSYNC.VERSION_4 Queue PERSON_DATA PERSON_DATA PERSON_DATA Subscription Handler App Package PersPoiFullSync PERSPOIFULLSYNC/PersPoiFullSync/OnNotify PersPoiSync PERSPOISYNC/PersPoiSync/OnNotify PersonBasicFullsync PERSON_BASIC_FULLSYNC/PersonBasicFullSync/OnNotify SCC_HR_PERSON SCC_HR_PERSON/PersonBasicSync/OnNotify ONNOTIFY PERSON_DISABILITY_FULLSYNC/PersonDisabilityFullsync/OnNoti fy ONNOTIFY PERSON_DISABILITY_SYNC/PersonDisabilitySync/OnNotify PersonDiversityFullSync PERSON_DIVERSITY_FULLSYNC/PersonDiversityFullsync/OnNotif y PersonDiversitySync PERSON_DIVERSITY_SYNC/PersonDiversitySync/OnNotify ONNOTIFY PERSON_VISA_CITIZEN_FULLSYNC1/PersonVisaCitizenFullSync1 /OnNotify ONNOTIFY PERSON_VISA_CITIZEN_FULLSYNC2/PersonVisaCitizenFullSync2 /OnNotify ONNOTIFY PERSON_VISA_CITIZEN_SYNC/PersonVisaCitizenSync/OnNotify WorkforceFullSync WORKFORCE_FULLSYNC/WorkforceFullSync/OnNotify WorkforceSync WORKFORCE_SYNC/WorkforceSync/OnNotify
PERSON_BASIC_SYNC.VERSION_4 PERSON_DISABILITY_FULLSYNC.VERSI ON_2 PERSON_DISABILITY_SYNC.VERISON_2 PERSON_DIVERSITY_FULLSYNC.VERSIO N_2 PERSON_DIVERSITY_SYNC.VERSION_2 PERSON_VISA_CITIZEN_FULLSYNC1.VE RSION_1 PERSON_VISA_CITIZEN_FULLSYNC2.VE RSION_1 PERSON_VISA_CITIZEN_SYNC.VERSION_ 1 WORKFORCE_FULLSYNC.VERSION_3 WORKFORCE_SYNC.VERSION_3
PERSON_DATA PERSON_DATA
PERSON_DATA
PERSON_DATA PERSON_DATA PERSON_DATA
Included in the deliverables to support CS HCM integrations are new versions for the PERSON_BASIC_SYNC/FULLSYNC, PERSON_DIVERSITY_SYNC/FULLSYNC and WORKFORCE_SYNC/FULLSYNC service operations and messages. These new versions include data that was not included in previous versions and was created specifically for integration between two HCM databases (e.g. 9.1 Talent Management integrations), and for integration between CS and HCM. At the moment, these new versions are not being used for integration between HCM and CRM, HCM and FSM, etc. Over time other products will develop subscriptions using the new message versions. An INTERNAL version has also been added as the new default for all three messages. Not that it is only for the local publication. No external databases should be subscribing to this version. The existing versions of the messages were not changed.
Page 14 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM The service operation routings for the integrations with other pillars should be created with the INTERNAL version and can be modeled on the delivered demo routings, e.g. PERSON_BASIC_SYNC_HR_TO_CR_V2, PERSON_DIVERSITY_SYNC_HR_EP_V1, WORKFORCE_FULL_HR_TO_LM_V1. The routing parameters are for the different message/versions are:
Message.ver into Transform 1 PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_DIVERSITY_SYNC.INTERNAL PERSON_DIVERSITY_SYNC.INTERNAL PERSON_DIVERSITY_FULLSYNC.INTERNA L PERSON_DIVERSITY_FULLSYNC.INTERNA L WORKFORCE_SYNC.INTERNAL WORKFORCE_SYNC.INTERNAL WORKFORCE_SYNC.INTERNAL WORKFORCE_SYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL
Transform Program 1 PDATA_SYNCV1 PDATA_SYNCV2 HMTF_TR_OA HMTF_TR_OA PDATA_FULLV1 PDATA_FULLV2 HMTF_TR_OA HMTF_TR_OA HCM_MSG_XFR M HMTF_TR_OA HCM_MSG_XFR M HMTF_TR_OA WORK_SYNCV1 HMTF_TR_OA HMTF_TR_OA HMTF_TR_OA WORK_FULL_V1 HMTF_TR_OA HMTF_TR_OA HMTF_TR_OA
Message.ver out of Transforms PERSON_BASIC_SYNC.VERSION_1 PERSON_BASIC_SYNC.VERSION_2 PERSON_BASIC_SYNC.VERSION_3 PERSON_BASIC_SYNC.VERSION_4 PERSON_BASIC_FULLSYNC.VERSION_1 PERSON_BASIC_FULLSYNC.VERSION_2 PERSON_BASIC_FULLSYNC.VERSION_3 PERSON_BASIC_FULLSYNC.VERSION_4 PERSON_DIVERSITY_SYNC.VERSION_1 PERSON_DIVERSITY_SYNC.VERSION_2 PERSON_DIVERSITY_FULLSYNC.VERSION_ 1 PERSON_DIVERSITY_FULLSYNC.VERSION_ 2 WORKFORCE_SYNC.VERSION_1 WORKFORCE_SYNC.VERSION_2 WORKFORCE_SYNC.VERSION_3 WORKFORCE_SYNC.VERSION_4 WORKFORCE_FULLSYNC.VERSION_1 WORKFORCE_FULLSYNC.VERSION_2 WORKFORCE_FULLSYNC.VERSION_3 WORKFORCE_FULLSYNC.VERSION_4
The new messages have been delivered in the following resolutions and bundles:
Release 9.1
PERSON_BASIC_SYNC/FULLSYNC and PERSON_DIVERSITY_SYNC/FULLSYNC WORKFORCE_SYNC
Resolution 835279 Resolution 837657
HR 9.1 Bundle #3 on 10/01/2010
Release 9.0
PERSON_BASIC_SYNC/FULLSYNC and PERSON_DIVERSITY_SYNC/FULLSYNC WORKFORCE_SYNC
Resolution 834256 Resolution 837135
HR 9.0 Bundle #14 on 10/15/2010
Page 15 of 136
Configuring Integration Broker Gateways and Nodes

Your CS and HCM systems must have appropriate connectivity established before you configure and run any fullsync or sync data load process. Please refer to Appendix A of this document for the appropriate steps to configure Integration Broker Gateways and Nodes in your CS and HCM systems.
Configuring FullS yn c Service Operations

This section of the document outlines the implementation steps for setting up and activating each FullSync service operation in Integration Broker. Repeat these steps for each FullSync integration you will use. Please refer to Appendix B for standard Fullsync configuration steps.
Configuring Incremental S ync Services

Once your Fullsync data loads are completed as necessary, you should configure and activate the appropriate Sync services to keep your CS and HCM systems updated with transaction data changes as they take place. The steps to configure Sync services in the publishing system of record, and subscribing target are the same as for Fullsyncs as documented in Appendix B. Refer to the table of Fullsync and Sync services for the appropriate Service name and Subscription Handlers to use. The following section details the setup required for PERSON_BASIC_SYNC - the primary Person transaction data related service. You will not need to execute the Full Data Publish Utility for incremental Sync services. Personal data changes made through online PIA pages and batch programs in your CS database will publish once you have configured and activated the appropriate Sync services.
Configuring PERSON_BAS IC_SYNC

The PERSON_BASIC_SYNC service is the primary integration point for syncing core personal data between your CS and HCM systems. The following tasks detail how to configure the PERSON_BASIC_SYNC service to publish from your CS 9.0 system and subscribe in the target HCM 9.0/9.1. Owner/Subscriber: If you implement the owner/subscriber model, you will configure your PERSON_BASIC_SYNC service to publish from your master CS 9.0 system to your target HCM 9.0/9.1 system. Subscriber Only: If you implement the subscriber only model, you will configure the PERSON_BASIC_SYNC service in both your CS 9.0 and HCM 9.0/9.1 systems to publish and subscribe.
Note: The examples shown for the source and target database configuration tasks are of CS 9.0 (source) and HCM 9.1 (target) on PeopleTools 8.51.03 Source Database CS 9.0 Configuration Tasks
1. Update security by adding the Service Operation(s) to your primary permission list:
a. b. c. d. e. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box. Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to use.. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page by selecting the Full Access option for the Access column.
Page 16 of 136
Figure 1 PERSON_BASIC_SYNC Web Serivce Access
2. Activate Service Operation(s) and Create Routing(s) in CS 9.0:

Go to PeopleTools > Integration Broker > Integration Setup > Service Operations. Select PERSON_BASIC_SYNC from the search dialog box. Check the Active check box on the General tab. Make note of the Queue Name field, as you will verify that the PERSON_DATA Queue is in Running status later. e. Click on the Routings tab and add a new routing for the Service Operation by entering a value in the Routing Name field and clicking the Add button. f. Enter a Sender Node and a Receiver Node on the Routings Definition page of the Routings component. g. Verify that the Active check box is checked. h. Click the Parameters tab. i. Enter External Alias = PERSON_BASIC_SYNC.VERSION_4 j. Enter Message.Ver into Transform 1 = PERSON_BASIC_SYNC.INTERNAL k. Enter Transform Program = HMTF_TR_OA l. Enter Message.Ver out of Transforms = PERSON_BASIC_SYNC.VERSION_4 m. Click the Save button at the bottom of the Parameters page to save the routing. n. Click the Return button at the bottom of the Parameters page to return to the Service Operation setup page. o. Save the Service Operation by clicking the Save button at the bottom of any of the pages in the Service Operations component. a. b. c. d.
Page 17 of 136
Figure 2 PERSON_BASIC_SYNC Service Operation
Page 18 of 136
Figure 3 PERSON_BASIC_SYNC Routings
Figure 4 PERSON_BASIC_SYNC Routing Definition
Page 19 of 136
Figure 5 PERSON_BASIC_SYNC Routing Parameters
Figure 6 PERSON_BASIC_SYNC Routing Graphic
Page 20 of 136
3. Activate Message Queue

p. q. r. Go to PeopleTools > Integration Broker > Service Operations Monitor > Administration > Queue Status. Scroll down the page until you find the relevant PERSON_DATA Queue Name. Review the queue Status and activate the queue by pushing the Run button if needed. The queue status should be set to Running before leaving this page.
Figure 7 PERSON_DATA Queue Status Target Database HCM 9.1 Configuration Tasks
1. Update security by adding the service operation to the required users permission list.
a. b. c. d. e. f. g. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box (primary permission list for the user). Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to leverage. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page. Click OK to return to the Web Services page. Click Save to save the updated Permission List.
Page 21 of 136
Figure 8 PERSON_BASIC_SYNC Service Permissions
2. Activate Service Operation(s) and Create Routing(s) and Subscription Handler in HCM 9.1:
Go to PeopleTools > Integration Broker > Integration Setup > Service Operations. Select PERSON_BASIC_SYNC from the search dialog box. Check the Active check box on the General tab. Make note of the Queue Name field, as you will verify that the PERSON_DATA Queue is in Running status later. e. Click on the Handlers tab. Set the SCC_HR_PERSON handler to Active f. Click on the Routings tab and add a new routing for the Service Operation by entering a value in the Routing Name field and clicking the Add button. g. Enter the CS 9.0 Sender Node and an HCM 9.1 Receiver Node on the Routings Definition page of the Routings component. h. Verify that the Active check box is checked. i. Click the Parameters tab. j. Enter External Alias = PERSON_BASIC_SYNC.VERSION_4 k. Enter Message.Ver into Transform 1 = PERSON_BASIC_SYNC.VERSION_4 l. Enter Transform Program = HMTF_TR_IA m. Enter Message.Ver out of Transforms = PERSON_BASIC_SYNC.INTERNAL n. Click the Save button at the bottom of the Parameters page to save the routing. o. Click the Return button at the bottom of the Parameters page to return to the Service Operation setup page. p. Save the Service Operation by clicking the Save button at the bottom of any of the pages in the Service Operations component. a. b. c. d.
Page 22 of 136
Figure 9 HCM 9.1 PERSON_BASIC_SYNC Service Operation
Page 23 of 136
Figure 10 HCM 9.1 PERSON_BASIC_SYNC Handlers
Figure 11 HCM 9.1 SCC_HR_PERSON Handler Details

Page 24 of 136
Figure 12 HCM 9.1 PERSON_BASIC_SYNC Routings
Page 25 of 136
Figure 13 HCM 9.1 PERSON_BASIC_SYNC Routing Definition
Page 26 of 136
Figure 14 HCM 9.1 PERSON_BASIC_SYNC Routing Parameters
Page 27 of 136
Figure 15 HCM 9.1 PERSON_BASIC_SYNC Routing Graphic
Configuring Person Batch Publish Processes

In addition to its normal processing (e.g., direct sql insert or update to bio demo data tables), the Campus Community common routine programs insert entries into message staging tables. The Enterprise Components Batch Publish (EOP_PUBLISHA) utility is then defined as a second process of a job definition (automated batch publish) to read the message staging tables and publish person messages. The Campus Community SQC Common Routines were enhanced in Release 8.9 (and still supported in Release 9.0) to implement the Batch Publish Design Pattern. Module cccmntpd.sqc cccupdnm.sqc cccgetad.sqc cccgetnm.sqc cccupdad.sqc cccupdcs.sqc cccmsgct.sqc Personal Data routines Update name Get Student Address Get Name Update Address Update-Citizenship-Status Reset SOA Batch Message Table Counters Description
The Person Batch Publish Process is used with several delivered CS SQR and Cobol processes. You will need to activate the appropriate Batch Publish rule to properly publish the person messages when these processes run.
Page 28 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Activate PERSON_BASIC_SYNC Publish Rule To activate the PERSON_BASIC_SYNC Batch Publish rule, navigate to Enterprise Components> Integration Definitions> Batch Publish Rules Select the PERSON_BASIC_SYNC Message Name Set Status = Active
Figure 16 PERSON_BASIC_SYNC Batch Publish Rule Activate PERSON_DIVERSITY_SYNC Publish Rule To activate the PERSON_DIVERSITY_SYNC Batch Publish rule, navigate to Enterprise Components> Integration Definitions> Batch Publish Rules Select the PERSON_DIVERSITY_SYNC Message Name Set Status = Active
Page 29 of 136
Figure 17 PERSON_DIVERSITY_SYNC Batch Publish Rule Handling Custom Programs If you plan to implement your CS HCM integrations following the Owner/Subscriber or Subscriber Only approach, you should thoroughly review your custom processes. Any of these custom processes which can add or update person bio-demo records should be evaluated and you should determine if you need them to publish the appropriate person messages. Depending on how your customizations are implemented, you may choose between any number of options to properly implement the methods to publish the necessary messages. Option 1: The most expedient action you can take is to incorporate the delivered SQC or COBOL modules in your current SQRs and COBOL programs. These modules contain the logic to stage the personal data being added or updated, and then batch publish message for creating a Person record (that is, publish the Person_Basic_Sync message). Option 2: If the custom batch jobs you are evaluating are designed to load Applicants, you may incorporate use of the Constituent and Application Transactions staging records and the Transaction Management process. These capabilities were delivered initially in July 2010 for the CS 9.0 codeline. (To find out more about this option, please see CS 9.0 Bundle #20 Functional Documentation and Additional Features January 2011 [ID 1282397.1] in My Oracle Support; Oracle's PeopleSoft Enterprise Campus Solutions 9.0 Admission Applications Web Services Developers Guide Appendix: Loading Applications in Bulk Depending on your external file layout, you may want to use the delivered File Parser utility to move constituent and application data into the appropriate staging tables. Option 3: If the custom batch jobs you are evaluating are designed to load Prospects, you may use the delivered Test Score Load processes, if appropriate. If your batch jobs for loading Prospects are not from a source included in delivered CS functionality (i.e. External Test Score , you may want to incorporate the batch publish design pattern in your custom batch jobs. Option 4: If your custom job uses an Application Engine process which was modeled after the CS Recruiting and Admissions Test Score Posting program (SAD_TEST_POST), then you have included the code needed to publish PERSON_BASIC_SYNC. Therefore, your custom Application Engine processes should not require modification.
Page 30 of 136
See Appendix D for further detailed instructions on the Batch Pubish Design Pattern, and technical guidance on how to implement this pattern in your custom programs. CS 9.0 includes a number of delivered programs which incorporate use of the batch publish design pattern. You may wish to consult some of these programs to help model any needed customizations. ADAPPPST.SQR (TS 189 Search/Match/Post) ADTRNPST.SQR (TS 130 Search/Match/Post) FAPSAR00 (COBOL, ISIR Inbound Load)
CHAPTER 4: UNDERSTANDING BUSINESS PROCESS IMPACTS IN

OWNER/SUBSCRIBER INTEGRATION
When you separate the CS and HCM database instances certain business processes are impacted, specifically the way your institution hires people, adds students, and updates bio-demo data for anyone. To integrate the two systems, you must configure the data ownership rules and adjust these business processes so that users enter data into the correct system and messaging sends it to the other. Adopting an owner/subscriber configuration model requires you to evaluate these business processes to determine how to configure integration services, deploying portal navigation changes, and to map any user data entry changes. A number of key business processes may be impacted by owner/subscriber integration. These are: 1. Hiring employees in HCM. 2. Hiring contingent workers in HCM 3. Adding people of interest (POI) in HCM. 4. Adding admissions applicants in CS. 5. Hiring faculty in both HCM and CS. 6. Batch data loads in CS:
Note. Standard HR department row-level security is not enforced on delivered CS components used to maintain person data. HR users will have access to all employee records through CS components. You will need to carefully plan which components you wish to deploy to your administrative users to manage personal information.
For more information, see the Implementing Portal Navigation Aggregation between CS and HCM guide.
The diagrams below demonstrate some high-level examples of these business processes, and how the data is messaged between your CS and HCM database.
Page 31 of 136
Figure 18 Example of hiring an employee
Figure 19 Example of hiring a contingent worker
Page 32 of 136
Figure 20 Example of adding a Person of Interest
Figure 21 Example of adding an admissions applicant in CS
Page 33 of 136
Figure 22 Example of hiring faculty
Figure 23 Example of loading batch data in CS
Page 34 of 136
Configuring the Last Employee ID Assigned Number

You will need to review and update the Last Employee ID Assigned number on the subscribing target system to prevent data integrity problems with conflicting EMPLID values being assigned. In an owner/subscriber configuration, the database instance that is the system of record for personal information is responsible for assigning the next EMPLID value. This step should be done with careful evaluation of the EMPLID number strategy you have implemented. Consider the following: Do you have custom EMPLID assignment routines that are used to set the next ID number? Do your users have established business practices that reserve certain number ranges?
To update the Last ID Assigned, navigate to Setup HRMS, Install, Installation Table. On the Last ID Assigned page, update the Last Employee ID Assigned field to the number desired.
Figure 24 Last ID Assigned Page in HRMS Setup
Page 35 of 136
Appendix A Configuring Integration Broker Gateways and Nodes

This appendix describes the steps to configure the Integration Broker Gateways and Nodes in your CS and HCM databases. Note: The steps detailed in the following tasks demonstrate the setup for an HCM 9.1 and CS 9.0 databases. 1. 2. 3. 4. 5. 6. 7. 8. 9. Set the Service Configuration in the HR 9.1 database Configure the Gateway in the HR 9.1 database Configure the default local node in the HR 9.1 database Configure the HR Gateway in the CS H900P7R2 database. Configure the CS node in the HR database Configure the default LOCAL node in the CS database Configure the HR node in the CS database Configure the CS node in the HR database. Update the HR Gateway nodes in the HR database
10. Update the HR Gateway nodes in the CS database. 11. Update the Single Sigonon nodes. 12. Testing Nodes
3. Setting the Service Configuration in the HR 9.1 database

a. b. c. d. e. Navigate: PeopleTools > Integration Broker > Configuration > Service Configuration. Set Service Namespace = 'http://xmlns.oracle.com/Enterprise/HCM/services'. Set Schema Namespace = 'http://xmlns.oracle.com/Enterprise/Tools/schemas' Set Target Location = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector Set Service System Status = 'Production'.
4. Configure the Gateway in the HCM 9.1 database

a. b. c. d. e. f. Navigate: PeopleTools > Integration Broker > Configuration > Gateways. Select Integration Gateway ID = 'LOCAL' Set URL = http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector/SPLTHL91' Click the 'Load Gateway Connectors' button. It should load 9 connectors. Save. Click the 'Ping Gateway' button. It should be successful and show the status as 'Active'.
5. Configure the default local node in the HCM 9.1 database

a. Navigate: PeopleTools > Integration Broker > Integration Setup > Nodes.
Page 36 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM b. c. d. e. f. g. h. i. j. k. l. Select the default local node. Set Descr = 'HCM 9.1 Instance'. Set Authentication Option = 'Password'. Node Password = 'PS'. Default User ID = 'PS'. Click the 'Connectors' tab. Use gateway ' LOCAL'. Set Connector Id = 'PSFTTARGET'. Click the Portal tab. Set Tools Release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string. Set Application Release = 'HCM 9.1'.
m. Set Content URI Text = ' http://machinename:port/psc/SPLTHL91'. n. o. p. q. r. Set Portal URI Text = ' http://machinename:port/psp/SPLTHL91'. Click the WS Security tab. Set Authentication Token Type = 'none'. Disable the 'encrypted' checkbox. Click Save
6. Configure the HCM Gateway in the CS 9.0 database.

a. b. c. d. e. f. g. Navigate: PeopleTools > Integration Broker > Configuration > Gateways Add a New Value Integration Gateway ID = <Gateway Name for HCM 9.1>. URL = http://machinename:port/PSIGW/PeopleSoftListeningConnector/databasename' Click the 'Load Gateway Connectors' button. It should load 9 connectors. Save. Click the 'Ping Gateway' button. It should be successful and show the status as 'Active'.
7. Configure the CS node in the HCM database
a. b. c. d. e. f.
Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes. Add Node = <Name of CS 9.0 Node> Set Descr = CS 9.0 Instance'. Set Authentication Option = 'Password'. Node Password = 'PS' Default User ID = 'PS'
Page 37 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM g. h. i. j. k. l. Click the 'Connectors' tab Set Gateway = ' LOCAL' Set Connector ID = 'PSFTTARGET' Click the Portal tab Set Tools Release = '8.50.xx (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string) Set Application Release = 'CS 9.0'.
m. Set Content URI Text = 'http://machinename:port/psc/databasename' n. o. p. q. r. Set Portal URI Text = 'http://machinename:port/psp/databasename'. Click the WS Security tab. Set Authentication Token Type = 'none'. Disable the 'Encrypted' checkbox. Click Save.
8. Configure the default LOCAL node in the CS database

[Note: the gateway used by this node is the HCM gateway. The node passwords must be consistent between the CS database and the HCM database.] a. b. c. d. e. f. g. h. i. j. k. l. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes Select the default local node Set Descr = CS 9.0 Instance'. Set Authentication Option = 'Password' Node Password = 'PS' Default User ID = 'PS' Click the 'Connectors' tab. Select Gateway = <Gateway Name for HCM 9.1> (Note: this is not the local gateway.) Set Connector Id = 'PSFTTARGET'. Click the Portal tab. Set Tools Release = '8.50.xx. (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string. Set Application Release = 'CS 9.0'.
m. Set Content URI Text = ' http://machinename:port/psc/databasename n. o. p. q. r. Set Portal URI Text = ' http://machinename:port /psp/databasename Click the WS Security tab. Set Authentication Token Type = 'none'. Disable the 'encrypted' checkbox. Click Save.
Page 38 of 136
9. Configure the HCM node in the CS database

[Note that each node is defined twice: once in each database. They should all use the same gateway.] a. b. c. d. e. f. g. h. i. j. k. l. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes. Add Node: <Name of HCM Node> Set Descr = HCM 9.1 Instance' Set Authentication Option = 'Password' Node Password = 'PS' Default User ID = 'PS' Click the 'Connectors' tab. Gateway ID = <Gateway Name for HCM 9.1> (Note: this is not the local gateway.) Set Connector Id = 'PSFTTARGET'. Click the Portal tab. Set Tools Release = '8.50.xx'. (Note: by pressing the <CTL>+J keys in the HR database PIA, you should be able to see the tools release string. Set Application Release = HCM 9.1
m. Set Content URI Text = ' http://machinename:port/psc/databasename n. o. p. q. r. s. Set Portal URI Text = ' http://machinename:port/psp/databasename Click the WS Security tab. Set Authentication Token Type = 'none'. Disable (turn off) the Encrypted checkbox. Click Save. Node Saved message box. Click OK.
10. Update the HCM Gateway nodes in the HCM database

Both CS and HCM database nodes should point to the same Gateway. The specific Gateway should also have both Nodes listed in the Gateway Advanced Properties. point to both nodes.
a. b. c. d. e. f. g.
Navigate: PeopleTools > Integration Broker > Configuration > Gateways. Select gateway 'LOCAL'. Select the 'Gateway Setup Properties' link. User ID = administrator Password = password Click OK. In the 'Gateway Default App. Server' frame, Set the App Server URL = ' //machinename:port (Note: your port must match that specified in your HCM application server.) Page 39 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM h. i. j. k. l. Enter the appropriate User ID Enter the appropriate Password Set the tools release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string.) Make sure both the HCM and CS nodes are in the 'PeopleSoft Nodes' tab
m. Ping the HCM node. It should be successful. n. Click return.
11. Update the HCM Gateway nodes in the CS database.

a. b. c. d. e. f. g. h. i. j. k. l. Navigate: PeopleTools > Integration Broker > Configuration > Gateways. Select gateway 'LOCAL'. Select the 'Gateway Setup Properties' link. User ID = administrator Password = password Click OK. In the 'Gateway Default App. Server' frame, Set the App Server URL = ' //machinename:port (Note: your port must match that specified in your HCM application server.) Enter the appropriate User ID Enter the appropriate Password Set the tools release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string.) Make sure both the HCM and CS nodes are in the 'PeopleSoft Nodes' tab
m. Ping the HCM node. It should be successful. n. Click return.
10. Update the Single Signon nodes in both CS and HCM databases
Single signon is used in this recommended configuration. a. b. Navigate: PeopleTools > Security > Security Objects > Single Signon. Make sure that both the default local node and the other node you will be using are listed.
11.
Testing Nodes
Both nodes must be 'pingable' from each database. a. b. c. Navigate: PeopleTools > Integration Broker > Service Operations Monitor > Administration> Node Status. Do this on each database. For each node name, enter its name and click the 'Ping Node' button. It should respond with 'Success'.
Page 40 of 136
Appendix B - Configuring FullSync Service Operations

This section of the document outlines the implementation steps for setting up and activating each FullSync service operation in Integration Broker. Repeat these steps for each FullSync service operation you will use.
Source Database Configuration Tasks

Note: The examples shown for the source database configuration tasks are of an HCM 9.1 database on PeopleTools 8.51.
12. Update security by adding the Service Operation(s) to your primary permission list:
a. b. c. d. e. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box. Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to use.. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page by selecting the Full Access option for the Access column.
Figure 25 Permission List Web Services Security
Page 41 of 136
Figure 26 Web Service Permissions Full Access
13. Activate Service Operation(s) and Create Routing(s):

q. r. s. t. u. Go to PeopleTools > Integration Broker > Integration Setup > Service Operations. Select the relevant Service Operation(s) from the search dialog box. Check the Active check box on the General tab. Make note of the Queue Name field, as you will need to verify that the Queue is in the Running status later. Click on the Routings tab and add a new routing for the Service Operation by entering a value in the Routing Name field and clicking the Add button.
Page 42 of 136
Figure 27 Service Operation Definition
Page 43 of 136
Figure 28 Service Operations Routings v. w. x. y. z. Enter a Sender Node and a Receiver Node on the Routings Definition page of the Routings component. Verify that the Active check box is checked. Click the Save button at the bottom of the Routings Definition page to save the routing. Click the Return button at the bottom of the Routings Definition page to return to the Service Operation setup component. Save the Service Operation by clicking the Save button at the bottom of any of the pages in the Service Operations component.
Page 44 of 136
Figure 29 Service Operation Routing Definitions Detail
14. Activate Message Queue

aa. Go to PeopleTools > Integration Broker > Service Operations Monitor > Administration > Queue Status. bb. Scroll down the page until you find the relevant Queue Name (from the Service Operation setup page noted earlier). cc. Review the queue Status and activate the queue by pushing the Run button if needed. The queue status should be set to Running before leaving this page.
Page 45 of 136
Figure 30 Queue Status
Target Database Configuration Tasks

Note: The examples shown for the target database configuration tasks are a CS 9.0 database on PeopleTools 8.51.
15. Update security by adding the service operation to the required users permission list.
a. b. c. d. e. f. g. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box (primary permission list for the user). Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to leverage. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page. Click OK to return to the Web Services page. Click Save to save the updated Permission List.
Page 46 of 136
Figure 31 Permission List Web Services Security
Figure 32 Web Services Permissions - Full Access
16. Activate Service Operation and Create Routing.

Page 47 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM a. b. c. d. Go to PeopleTools > Integration Broker > Integration Setup > Service Operations. Select the relevant Service Operation(s) from the search dialog box. Check the Active check box on the General tab. Make note of the Queue Name field, as you will need to verify that the Queue is in the Running status later.
Figure 33 Service Operation Definition e. f. g. h. i. j. Click on the Routings tab and add a new routing for the Service Operation. Enter a Sender Node and a Receiver Node on the Routings Definition page of the Routings component. Verify that the Active check box is checked. Click the Save button at the bottom of the Routings Definition page to save the routing. Click the Return button at the bottom of the Routings Definition page to return to the Service Operation setup component. Save the Service Operation by clicking the Save button at the bottom of any of the pages in the Service Operations component.
Page 48 of 136
Figure 34 Service Operation Routings
Figure 35 Routing Definitions
17. Activate or create the required Service Operations OnNotify handler.

a. b. c. Click on the Handlers tab of the Service Operations component. Enter a Handler Name as shown below if one does not exist. Set Handler Name = [please see Table 1 Full Sync Service Operations table below (Application Package Name/ Class/ Method column) for the required value for this field. (example: BusUnitHRFullSync)] Page 49 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM d. e. f. g. h. i. j. k. l. Set Type = OnNotify Set Implementation = Application Class Set Status = Active Click on Details link Set Package Name = [see Table 2 FullSync Service Operations listed above (Application Package Name/ Class/ Method column) for the required value for this field. (Example: GEN_UPG_HANDLER_12332 )] Set Path = : Set Class ID = [see Table 2 FullSync Service Operations listed above (Application Package Name/ Class/ Method column) for the required value for this field. (Example: CountryFullSync) Set Method = OnNotify Click OK to return to the Handlers setup page.
m. Click Save button at the bottom of the Handlers page to save your changes.
Figure 36 Service Handlers
Page 50 of 136
Figure 37 Handler Details
18. Activate Message Queue.

a. b. c. Go to PeopleTools > Integration Broker > Service Operations Monitor > Administration > Queue Status. Scroll down the page until you find the relevant Queue Name (from the Service Operation setup page noted earlier). Review the queue Status and activate the queue by pushing the Run button if needed.
Executing the Full Data Publish Utilit y

Run the Full Data Publish process to synchronize the data between your HCM and CS systems.
19. Define Full Data Publish Rules

a. Go to Enterprise Components > Integration Definitions > Full Data Publish Rules. b. c. d. e. Enter the Message Name of the Service Operation Enter a Publish Rule ID, a Description, and set the Status field to Active Check the Create Message Header and Create Message Trailer check boxes. Save the page.
Page 51 of 136
Figure 38 Full Table Publish Rules
20. Execute the Full Data Publish Process

a. b. c. d. e. f. g. h. Go to Enterprise Components > Integration Definitions > Initiate Processes. Create a new Run Control ID as shown below. Enter a Request ID. Select Always for the Process Frequency. Enter the Message Name from the Full Table Publish Rule created earlier (example: COUNTRY_FULLSYNC). Save the page and click the Run button. Select the Full Table Data Publish process from the Process Scheduler Request page. Verify the process ran successfully.
Page 52 of 136
Figure 39 Full Data Publish
Figure 40 Process Scheduler Request 1. Go to PeopleTools > Integration Broker > Service Operations Monitor > Monitoring > Aynchronous Services to review the status of the Full Sync messages created by the Full Data Publish process.
Page 53 of 136
Figure 41 Asynchronous Service Operations Monitor
Page 54 of 136
Appendix C Fullsync and Sync Service Operations Included Fields

This appendix details the included fields in each of the Fullsync and Sync message structures. It is for reference only. Message Versions are current as of November 2010, and are shown for CS 9.0 (HRCS 9.0).
Page 55 of 136
Page 56 of 136
Page 57 of 136
Page 58 of 136
Page 59 of 136
Page 60 of 136
Figure 42 PERSON_BASIC_FULLSYNC.VERSION_4
Page 61 of 136
Page 62 of 136
Page 63 of 136
Page 64 of 136
Page 65 of 136
Page 66 of 136
Figure 43 PERSON_BASIC_SYNC.VERSION_4
Figure 44 PERS_POI_FULLSYNC
Page 67 of 136
Figure 45 PERS_POI_SYNC
Page 68 of 136
Page 69 of 136
Page 70 of 136
Figure 46 PERSON_DISABILITY_FULLSYNC.VERSION_2
Page 71 of 136
Page 72 of 136
Page 73 of 136
Page 74 of 136
Figure 47 PERSON_DISABILITY_SYNC.VERSION_2
Page 75 of 136
Figure 48 PERSON_DIVERSITY_FULLSYNC.VERSION_2
Page 76 of 136
Figure 49 PERSON_DIVERSITY_SYNC
Page 77 of 136
Figure 50 PERSON_VISA_CITIZEN_FULLSYNC.VERSION_1
Page 78 of 136
Figure 51 PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1
Page 79 of 136
Page 80 of 136
Figure 52 PERSON_VISA_CITIZEN_SYNC.VERSION_2
Page 81 of 136
Page 82 of 136
Page 83 of 136
Page 84 of 136
Page 85 of 136
Page 86 of 136
Page 87 of 136
Page 88 of 136
Page 89 of 136
Page 90 of 136
Page 91 of 136
Page 92 of 136
Page 93 of 136
Page 94 of 136
Figure 53 WORKFORCE_FULLSYNC.VERSION_3
Page 95 of 136
Page 96 of 136
Page 97 of 136
Page 98 of 136
Page 99 of 136
Page 100 of 136
Page 101 of 136
Page 102 of 136
Page 103 of 136
Page 104 of 136
Page 105 of 136
Page 106 of 136
Page 107 of 136
Page 108 of 136
Figure 54 WORKFORCE_SYNC.VERSION_3
Page 109 of 136
Appendix D Batch Publish Design Pattern

This appendix details the batch publish design pattern. It includes content originally published under the PeopleSoft 8 Enterprise Integration PeopleBooks. This content is still also available at the following URL: http://peoplebooks.peoplesoft.com/htmldoc/hrms8/eng/psbooks/ei/chapter.htm?File=ei/htm/eicome38.htm This design pattern addresses the need to publish messages from a batch application. The batch application may be a SQR program that takes either a procedural (row by row) or set based approach, or it may be an AE set-based program. Currently, there are no utilities that permit publishing a message directly from a SQR program. This design pattern addresses how to publish such messages by flagging records for later publication. It solves the problem of Set processing that handles hundreds of rows at a time when there is no flag to indicate which particular rows need to be published. Publishing from these batch programs requires two processes: 1. In addition to its normal processing, the batch program must either mark the rows for publishing by updating the Audit Action, Process Instance and In Process Flag field for the rows that were changed, or insert the updated rows into staging tables. 2. A generic Batch Publish program publishes the data from the marked rows. The Batch Publish program may be run as a second process of a job definition (automated batch publish) or submitted from an online page as a standalone process (manual batch publish). Application AE programs may optionally call the Batch Publish program directly. PeopleSoft has provided a generic publishing program. You'll need to modify the batch program to update specific fields (or write modified rows to staging tables), and insert a row into the Batch Parameter Table that provides the Batch Publish program with the data it needs to publish. The SQR or AE program may flag rows to be processed in one of the following ways: One method is to flag existing PeopleSoft application tables. This method requires that three additional fields, AUDIT_ACTN, PROCESS_INSTANCE and IN_PROCESS_FLG be added to each application table defined in the Message Definition Table. Another method is to use staging tables. For each application table defined in the Message Definition, a separate staging table will need to be defined. Fields in the staging tables must have exactly the same names as fields in Message Definition. The staging table must also contain the fields AUDIT_ACTN, PROCESS_INSTANCE and IN_PROCESS_FLG.
Note. If updates or inserts are made to a row below level zero, all parent rows must also be updated with the process instance (the Audit Action and In Progress Flags may be left blank). This will allow the AE generic Batch Publish program to easily select the transactions that need to be published by reading the parent/child chain by Process Instance. You may need to provide additional logic that selects additional rows and marks them if the current application logic only affects some of the records within the message structure. Upon completion of processing, the Application Batch program must insert a single row containing the fields required by the Batch Publish program into a Batch Publish Parameter Table. PeopleSoft will provide the common code (an SQC or AE Section) for writing to the parameter table. The Batch Publish program selects all of the changed data based on the data in the parameter table and copies it from the Record Object to a Message Object. After all rows (parent and child) are inserted in the Message Object for a logical unit of work, the message size is compared to the MaxMessageSize parameter. If the message exceeds MaxMessageSize, it issues the Publish() command to publish the message, and creates a new Message Object. Otherwise the next LUW is added to the message. After processing all changed data, the Batch Publish
Page 110 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM program will update the status in the parameter table to Complete, and either update the process instance, audit action, and process flag in the application tables or delete the rows from the staging tables. If Message Chunking has been set up for the message a separate message is published for each new value of the chunking field(s). The Batch Publish program will optionally produce a header and trailer message for all subscribers to the message. The messages will be delivered to the subscribing system in the order in which they are published. Note. Batch Publish is an incremental publish, and as such, only publishes in the user's base language. For example, if the base language is English and the message data is chunked by Business Unit, the messages created by the Batch publish program could be: 1. Header message (optional) 2. English Business Unit A message 3. English Business Unit B message 4. .... 5. English Business Unit Z message 6. Trailer message (optional) For more information about message chunking and routing, header and trailer information and the Publish Definition page, see Setting Up Message Publishing.
Topics
When You Should Use This Design Pattern When You Shouldn't Use This Design Pattern Process Flow Automated Version Process Flow Manual Version
When You Should Use This Design Pattern

When your message data to be published is being triggered by a change done within an SQR or AE program. When one or more third party applications needs the data asynchronously.
Examples To publish Incremental Changes from large transactions such as the Payroll Acknowledgement of Expense Payment Request or Inventory Shipping Transaction.
When You Shouldn't Use This Design Pattern

When the message data to be published is being triggered by a change done within a component. When the receiving application is waiting for the 'answer' in real-time before it can continue processing. When you wish to publish the complete contents of a table for replication to another system. Use the Full Data Publish design pattern instead.
Page 111 of 136
Process Flow Automated Version
Automated Batch Publish Process Flow
Process Steps 1. Application batch program (1) and Batch Publish Utility program (4) are part of the same Job Definition and can only run on the Server. 2. The application program will either insert modified rows to a staging table, or flag modified rows in PeopleSoft Application Tables (2). 3. A single row is inserted in a Batch Parameter table (3) that contains the parameters needed by the AE publishing program as a trigger to publish that batch programs data. 4. The Batch Publish program (4)selects all of the changed data based on the parameters in the Batch Parameter table and publishes the message(s) (5).
Page 112 of 136
Process Flow Manual Version
Manual Batch Publish Process Flow
Process Steps 1. Application batch program is run as standalone process. Process can run on Client or Server.
Page 113 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM 2. The application program will either insert modified rows to a staging table, or flag modified rows in PeopleSoft Application Tables. 3. A single row is inserted in a Batch Parameter table that contains the parameters needed by the AE publishing program as a trigger to publish that batch programs data. 4. Batch Publish may be scheduled from an online page. 5. Online parameter file contains the application batch program (step 1). 6. The Batch Publish program selects all of the changed data based on the parameters in the Online and Batch Parameter tables and publishes the message(s).
Developer Activities
To design a Batch Publish EIP:
1. Determine Batch Publish process method 2. Identify Source tables for batch publish 3. Create or modify source tables 4. Create the Message Definition 5. Create the Publish Definition 6. Create Chunking Rules 7. Modify the application batch program 8. Create Automated Publish Job Definition, if using the automated process 9. Create Manual Publish Run Control, if using the manual process 10. Test
Topics
Activity 1 Determine Batch Publish Process Method Activity 2 Identify Source Tables for Batch Publish Activity 3 Create or Modify Source Tables Activity 4 Create the Message Definition Activity 5 Create the Publish Definition Activity 6 Create Chunking Rules Activity 7 Modify the Application Batch Program Activity 8 Create Automated Publish Job Definition Activity 9 Create Manual Publish Run Control Activity 10 Test
Activit y 1 Determine Batch Publish Process Method

Summary of considerations Automated Batch Publish Process (SQR) o o o Need to create Job Definition Job can only run on Server Publish is done when batch application finishes Page 114 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM o o o o o o o Automated Batch Publish Process (AE) Publish is done as last step in application AE program No restrictions on where processes can run Manual Batch Publish Process Need to schedule the batch publish process No restrictions on where processes can run May be a substantial delay between the time the data is flagged for publish and when the actual publish takes place. This could cause problems if application tables are being flagged and the user is not locked from making changes. Could also cause problems for the user if they have to wait for the publish program to run before making online changes.
We show two use cases below, one calling Batch Publish from an AE program and the other use case showing Batch Publish being run after an SQR program. Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) When Expenses sends Payroll a Request for Payment, Payroll must send back a message acknowledging the request. As this new business process added functionality, Payroll decided to write a new AE program, PY_EXPVALIDT. The new AE program would read the Expense Request message, validate the data and store a copy of the original message data with the status of accepted or rejected in staging tables, then publish a message back using the staging tables to the Expenses system. The Batch program could delete the staging tables immediately after the message was published. The new AE program could also leverage the fact that the Batch Publish program was also written in AE and could call the Batch Publish program directly as the last step within the new AE program. Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) When Payroll creates Paychecks, it must notify Expenses of this fact by sending out a Payment Issued message. An existing program, PAYGL01.SQR contains the logic to create the data needed for the Payment Issued message, so it was decided to modify this program to write payment data to a staging table and publish the staging table by calling Batch Publish with a separate manual job. The Batch Publish program would then delete the staging tables immediately after the message was published.
Activit y 2 Identify Source Tables for Batch Publish

Source/Order By tables contain the data from which the Publish utility program selects and adds to the message. Source tables can be existing application tables, staging tables, or views. Set processing batch programs may have temporary tables that contain data that's been changed during processing. If this is the case, it's more efficient to use those instead of application tables as source tables. Performance of the Batch Publish Select statements will be slower against an application table than against a temp table that holds only changed data. For SQR row by row batch programs, the source tables are likely to be the application data tables. It's possible to create a set of temporary tables for this purpose, if there's some reason to avoid adding process instance, audit action, and in process fields to application tables. Beware of the performance implications of this choice, since it's likely to double the number of trips to the database with an extra insert to the staging table for every insert or update to the application tables. Note. If you use temp tables as source tables, the Delete statements to clear them need to be at the beginning of the batch program, not at the end. Summary of considerations Using existing application tables
Page 115 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Requires addition of the following fields to each table: Process Instance Audit Action In Process Flag Does not handle deletes. Allows the ability for Application Batch programs and online pages to restrict updates until message is sent. Requires application program to flag records to be published at each level.
Using staging tables Requires creation of new tables (possibly). Staging tables must contain same field names as tables in message definition. Staging tables require the following additional fields: Process Instance Audit Action In Process Flag Will handle deletes. Does not allow Application Batch programs and online pages to restrict updates until message is sent.
Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) For the Payroll Acknowledgement message, in order to avoid any conceivable complications by publishing from the application tables, a staging table was created that would contain a copy of the application data. This way, the original application tables that were needed for the next step in the Payroll process would not need to be modified if the contents of the Acknowledgement message had to be changed. The original application record name was PAY_ACKNOWLEDGE. The staging table created was called PAY_ACK_STG_PUB. Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) Since this was an existing SQR program and since Payroll did not want to worry about the messaging data requirements affecting the processing on the payment issuing application tables, staging tables would be created that would contain a copy of the application tables needed for the Payment Issued message. The original application record name was PAY_ISSUED. The staging table created was called PAY_ISS_STG_PUB.
Activit y 3 Create or Modify Source Tables

The Batch Publish program needs to know two things from the application batch program: 1. Which rows were affected 2. How they were affected (add, change, delete). Two fields on each source table identify this information: process instance identifies which and audit action shows how. The batch program has to populate these fields at the time it updates or inserts data. The requirements for a source table are the following: It must contain the field AUDIT_ACTN, to set the audit action. The audit action field AUDIT_ACTN is currently used only for the PeopleTools Record Audit functionality. In release 8, it will be used by Application Messaging as well. The valid values remain the same: A - Row inserted. D - Row deleted.
Page 116 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM C - Row changed but no key fields changed. The old values are written to the audit table. K - At least one key field changed. The old values are written to the audit table. N - At least one key field changed. The new values are written to the audit table. It must contain the field PROCESS_INSTANCE to identify data that was changed by a particular batch run. The process instance field on the source tables is necessary to support processing in parallel. It provides applicationcontrolled row locking. In set processing, the Application Batch program selects rows from the application tables where PROCESS_INSTANCE=0. It updates process instance in the application tables to lock the rows. When processing is complete and application tables have been updated, it usually zeroes out process instance to release the data for other processes. This last step now becomes the responsibility of the AE generic Batch Publish program. It must contain the field IN_PROCESS_FLAG. This field is currently being used by Purchase Order Management to lock the row from being updated online. Fields that are in the source table and in the message definition must have the same name. The source tables do not need to be the same as the tables that comprise the message definition. This means you can publish data from tables A, B, and C using a message definition that references tables X, Y, and Z. For example, suppose you want to delete records from an application table. When you publish a message based on this table, the deleted records are no longer in the table, and therefore not published. Instead, you can load the deleted rows into a staging table, then publish the message, specifying that the data in the staging table be used instead of the data in the application table.
Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) The PAY_ACK_STG_PUB staging record was created to store the Expense Payment Request Acknowledgment information and set an acceptance status depending if the line item passed payroll validations or not. This table would be used to publish the message and would be deleted after the message was published. Besides the fields needed for the message only the AUDIT_ACTN and PROCESS_INSTANCE fields were added. No chunking is needed on this message at this time.
PAY_ACK_STG_PUB Staging Record Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) The PAY_ISS_STG_PUB staging record was created to store the data needed for the Payment Issued message that needs to be published. Again since this is a staging record, besides the data in the original Paysheet fields, only additional fields for AUDIT_ACTN and PROCESS_INSTANCE needed by the Batch Publish program were added.
PAY_ISS_STG_PUB Staging Record
Activit y 4 Create the Message Definition

Create new views or tables as needed for the message definition. Using the Application Designer, you need to create the message definition that contains the records to be replicated. In addition, you may need to create the message channel and the message node. For more information about message definitions, channels, and nodes, see PeopleTools Application Messaging documentation. Your message definition records should not include AUDIT_ACTN, PROCESS_INSTANCE or IN_PROCESS_FLAG fields. They are unnecessary in the message itself. AUDIT_ACTN values the application or staging table will be moved into the PSCAMA.AUDIT_ACTN field that is automatically tacked onto each row of the message. The other fields are strictly for the Batch Publish Program and should not be exposed to external vendors.
Page 117 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) Message PAYMENT_EXPENSES_ACKNOWLEDGE was created to consist of a single record, PAY_ACKNOWLEDGE and it contains the same application fields as its staging table, PAY_ACK_STG_PUB.
PAYMENT_EXPENSES_ACKNOWLEDGE Message Definition Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) Message PAYMENT_EXPENSES_ISSUE was created to consist of a single record, PAY_ISSUED and contains the same application fields as the staging record, PAY_ISS_STG_PUB.
PAYMENT_EXPENSES_ISSUE Message Definition
Activit y 5 Create the Publish Definition

Go, Define Business Rules, Manage Integration Rules, Use, Batch Publish Rules On the Publish Definition page, you must specify a publish name. This is the name you will use for this publish. You only need to fill out information on the Source Record Mapping page if you want to specify a different record for the source data for a record in a message. On the Batch Programs page, you must fill out the name of the batch application program that is being run prior to the publish, that is marking which data needs to be published, setting the AUDIT_ACTN field, etc. For more information about how to create a Chunking Rule or Publish Rule and entering information on the Publish Definition, Source Record Mapping and Batch pages, see Setting up Application Messaging EIPs. Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) A new Publish Rule, PAY_ACKNOWLEDGE, is added that will publish the entire contents of the PAYMENT_EXPENSES_ACKNOLWEDGE message without chunking it.
Publish Rule Definition Panel for PAYMENT_EXPENSES_ACKNOWLEDGE PAY_ACK_STG_PUB is entered as the publish staging table for the PAY_ACKNOWLEDGE message record within the Publish Rule.
Publish Rule Record Mapping Panel for PAYMENT_EXPENSES_ACKNOWLEDGE The application program name, PY_EXPVALIDT is entered as the Batch Program name for the Publish Rule.
Publish Rule Batch Programs Panel for PAYMENT_EXPENSES_ACKNOWLEDGE Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) A new Publish Rule, PAY_ISSUED, is added that will publish the entire contents of the PAYMENT_EXPENSES_ISSUE message without chunking it.
Page 118 of 136
Publish Rule Definition Panel for PAYMENT_EXPENSES_ISSUE PAY_ISS_STG_PUB is entered as the publish staging table for the PAY_ISSUED message record within the Publish Rule.
Publish Rule Record Mapping Panel for PAYMENT_EXPENSES_ISSUE The application program name, PAYGL01, is entered as the Batch Program name for the Publish Rule.
Publish Rule Batch Programs Panel for PAYMENT_EXPENSES_ISSUE
Activit y 6 Create Chunking Rules

If you're using message chunking, you need to fill out other fields on this page. For more information about chunking, see Setting Up Message Chunking. Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) The message PAYMENT_EXPENSES_ACKNOWLEDGE is not being chunked so we skip this step. Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) The message PAYMENT_EXPENSES_ISSUE is not being chunked so we skip this step.
Activit y 7 Modify the Application Batch Program Topics

Retrieving the job instance Adding logic to check for active publish definitions Modifying the SQL to select only records with PROCESS_INSTANCE = 0 Modifying the SQL to update the Audit Action, Process Instance and In Process flags Modifying application programs to pass parameters via the Parameter Table Retrieving the job instance The following routines will retrieve the JOBINSTANCE. The JOBINSTANCE is used by the Batch Publish program to find the Batch Parameter record created by the application batch program when doing a automated batch publish. The application batch program should always use the PROCESS_INSTANCE to update the source tables. For AE programs: 1. Add State Record EO_BATLIB_AET to your AE program 2. Set PROCESS_INSTANCE in EO_BATLIB_AET 3. Call Section GETJOB in EOL_PUBLISH
Page 119 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM 4. This will return field JOBINSTANCE in EO_BATLIB_AET For SQR Programs: 1. Include stdapi.sqc in your program 2. Call Get-Run-Control-Parms 3. This will return #prcs_job_instance and #prcs_process_instance Adding logic to check for active publish definitions This is an optional step. The following routines will return a count of the active messages to be published by this program. If there are no active messages to publish then appropriate logic can be invoked. For example the application program could abort processing or logic could be added that would clear the IN_PROCESS_FLG when the program completes. For AE programs: 1. Add state record EO_BATLIB_AET to your AE program 2. Set PROCESS_NAME in EO_BATLIB_AET to the PROCESS_NAME of your AE program 3. Call section ACTIVE in EOL_PUBLISH 4. Field ACTIVE in EO_BATLIB_AET will contain the count of active Publish Rules to be published For SQR Programs: 1. Include EOPRCSNM.SQC, EOPARAM and EOACTIVE.SQC 2. Call Get-Active-In-BatchPub 3. Returns #cntmsg (count of active Publish Rules to be published) Modifying the SQL to select only records with PROCESS_INSTANCE = 0 You'll need to find the place in the SQL code that selects the source data for update to make this modification. The process instance field is used to lock rows of data from processing until the Batch Publish has published the message for those rows. The Batch Publish program will then update value the process instance field to zero. Only rows with a zero value in the process instance field are available for further updates. Example of a modified Select
SELECT FIELD_1, FIELD_2 FROM PS_APPL_TBL WHERE BUSINESS_UNIT=$BU AND ITEM_ID='1234' AND PROCESS_INSTANCE=0; Example of a modified Update: UPDATE PS_APPL_TBL SET FIELD_1='A', FIELD_2=[$AsOfToday], PROCESS_INSTANCE=#PROCESS_INSTANCE, PROCESS_INSTANCE=#PROCESS_INSTANCE, AUDIT_ACTN='C' WHERE BUSINESS_UNIT=$BU AND ITEM_ID='1234' AND
PROCESS_INSTANCE=0;
Page 120 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Modifying the SQL to update the Audit Action, Process Instance and In Process flags You'll need to find the place in the SQL code that updates or inserts data into the Source Tables to make this modification. The batch program has to populate the AUDIT_ACTN, PROCESS_INSTANCE and IN_PROCESS_FLG fields at the time it updates or inserts data. If the batch program adds a row, it must set AUDIT_ACTN=A on that row in the source table. If the batch program changes a row, it must set AUDIT_ACTN=C in the source table. If the batch program deletes a row, it must set AUDIT_ACTN=D in the source table (Must use staging tables for deletes). The PROCESS_INSTANCE is set to the actual process instance of the Batch Program. Example of a modified Insert
INSERT INTO PS_APPL_TBL (FIELD_1, FIELD_2, PROCESS_INSTANCE, AUDIT_ACTN) AUDIT_ACTN VALUES ('A', $AsOfToday, #PROCESS_INSTANCE, 'A' Example of a modified Update: UPDATE PS_APPL_TBL SET FIELD_1='A', FIELD_2=[$AsOfToday], PROCESS_INSTANCE=#PROCESS_INSTANCE, AUDIT_ACTN='C' WHERE BUSINESS_UNIT=$BU AND ITEM_ID='1234' AND
PROCESS_INSTANCE=0;
AE Set Processing Example An Update statement with a Where clause that affects multiple rows is fairly straightforward. What's more common is achieving an update by selecting rows from one temp table, inserting them into another temp table, and changing values along the way. The following sample addresses that scenario. Note that although the statement is an Insert, the audit action is 'C'.
INSERT INTO PS_TMPA_TBL (PROCESS_INSTANCE GROUP_BU, PROCESS_INSTANCE, PROCESS_INSTANCE GROUP_ID, OPRID, ASSN_OPRID, BUSINESS_UNIT, GROUP_TYPE, BAL_STATUS, EDIT_STATUS, POST_STATUS,... AUDIT_ACTN AUDIT_ACTN) SELECT &BIND(PROCESS_INSTANCE), G.GROUP_BU, G.GROUP_ID, G.OPRID, G.ASSN_OPRID, G.BUSINESS_UNIT, G.GROUP_TYPE, T.BAL_STATUS, 'E', 'E',... 'C') 'C' FROM PS_TMPT_TBL, PS_GROUP_CONTROL G, PS_TMPP_TBL P WHERE T.PROCESS_INSTANCE = &BIND(PROCESS_INSTANCE) AND G.GROUP_BU = T.GROUP_BU AND G.GROUP_ID = T.GROUP_ID AND P.PROCESS_INSTANCE = &BIND(PROCESS_INSTANCE) AND P.GROUP_BU = G.GROUP_BU AND P.GROUP_ID = G.GROUP_ID
GROUP BY G.GROUP_BU, G.GROUP_ID, G.OPRID, G.ASSN_OPRID, G.BUSINESS_UNIT, G.GROUP_TYPE, T.BAL_STATUS, G.CONTROL_AMT, G.CONTROL_CNT...
Modifying application programs to pass parameters via the Parameter Table The application program passes parameters to the Batch Publish program by inserting a single row into a Batch Parameter table. The Batch Publish program uses the parameters, process instance, and program name to pull control data from setup tables that define what is published from each program. The following routines will update the Batch Parameter table.
Page 121 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM For AE programs: 1. Add State Record EO_BATLIB_AET to your AE program 2. Set Fields JOBINSTANCE, PROCESS_INSTANCE and PROCESS_NAME in EO_BATLIB_AET. This will not be necessary if Sections GETJOB and ACTIVE were called earlier in your AE program 3. Set field BATCH_CLEANUP_FLG. Valid values and actions are: o o o o 4. Blank - No cleanup of source table data is done D - Published rows are deleted from the source table U - IN_PROCESS_FLG of published rows is set to "X" C - IN_PROCESS_FLG and AUDIT_ACTN of published rows is set to blanks and PROCESS_INSTANCE is set to zero
Call Section INSPARM in EOL_PUBLISH
For SQR Programs: 1. Include EOPARAM.SQC in your program 2. Set $batch_cleanup_flg. Valid values and actions are: o o o o 3. Blank - No cleanup of source table data is done D - Published rows are deleted from the source table U - IN_PROCESS_FLG of published rows is set to "X" C - IN_PROCESS_FLG and AUDIT_ACTN of published rows is set to blanks and PROCESS_INSTANCE is set to zero
Call Insert-Param-In-BatchPub
The following table describes the parameters for this procedure: Parameter PROCESS_INSTANCE Key Yes Description PROCESS_INSTANCE of the COBOL, SQR, or Batch program which flagged the records for publishing. The AE Publish program will use this value to find the records modified by the application program. JOBINSTANCE of the COBOL, SQR, or Batch program which flagged the records for publishing. This field will contain a zero if the batch program ran as a standalone process. In the automated publish process the AE Publish Program will use the JOBINSTANCE to find the PROCESS_NAME it needs to publish. The name of the COBOL, SQR, or AE program. This field is the key to the control data used to structure the message. Application batch programs will populate this field with an 'N' (Pending). The Batch Publish program will change it to 'P' (Processing) while the publish is in process and to a 'C' (Complete) when the publish is done. This field must be set by the application program prior to calling the generic function for inserting the row. The valid values and their actions are: Blank - no cleanup processing is done. D - the published rows are deleted from the source table.
JOBINSTANCE
Yes
PROCESS_NAME
PROCESS_STATUS
BATCH_CLEANUP_FLG
Page 122 of 136
U - the IN_PROCESS_FLG is set to "X" for published rows. C - the IN_PROCESS_FLG and AUDIT_ACTN are set to blank and PROCESS_INSTANCE is set to zero for all published rows. DATETIMESTAMP The application program will populate this field. Used for information only.
Calling Batch Publish Directly from a Application AE program If the application batch program is an AE program, the Batch Publish AE program may be called as the last step of the application AE program. This will eliminate the need to create a Job Definition. The following logic will call the Batch Publish program directly. For AE programs: 1. Add State Record EO_BATLIB_AET to your AE program 2. Set Fields JOBINSTANCE, PROCESS_INSTANCE and PROCESS_NAME in EO_BATLIB_AET. This will not be necessary if Sections GETJOB and ACTIVE were called earlier in your AE program 3. Set field MSGNODENAME. If a value is entered in this field the Publish utility will copy it to the PSCAMA record in the message object. Routing peoplecode can then be written to return the value to the app server for routing. 4. Call Section PUBLISH in EOL_PUBLISH Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) Here's the PY_EXPVALIDT program:
PY_EXPVALIDT AE Program Part One
PY_EXPVALIDT AE Program Part Two State record EO_BATLIB_AET was added to the application AE program PY_EXPVALIDT.
Adding Records to PY_EXPVALIDT In section INITPROG, a new step, STEP01, performs PeopleCode to update the PROCESS_INSTANCE in the staging table:
UPDATE PS_PAY_RQT_STG_SUB %Bind(PROCESS_INSTANCE) SET PROCESS_INSTANCE =
In section INITPROG, a new step, STEP02, performs PeopleCode to set the PROCESS_INSTANCE in state record EO_BATLIB_AET:
%Select(EO_BATLIB_AET.PROCESS_INSTANCE, EO_BATLIB_AET.PRCSINSTANCE, EO_BATLIB_AET.JOBINSTANCE, EO_BATLIB_AET.PROCESS_NAME) JOBINSTANCE , PRCSNAME %Bind(PROCESS_INSTANCE) SELECT PRCSINSTANCE , PRCSINSTANCE , FROM PSPRCSRQST WHERE PRCSINSTANCE =
In section VALIDATE, a new step, STEP02, inserts data into the Publish staging table and set the AUDIT_ACTN and PROCESS_INSTANCE fields. The AUDIT_ACTN get set to 'A' or 'C' or 'D".
UPDATE PS_PAY_RQT_STG_SUB SET PROCESS_INSTANCE =
Page 123 of 136
%Bind(PROCESS_INSTANCE), AUDIT_ACTN = 'A'
Valid employee numbers, earnings codes, currency codes, and amounts were inserted into staging tables, and bad earnings codes, bad employee numbers, bad currency codes, bad amounts and invalid paysheets were inserted into the staging table. Logic to check if PROCESS_INSTANCE = 0 on the select statements before inserting to the publish staging tables wasn't necessary as we are publishing from the staging tables not from application tables. Below shows SQL for bad earnings codes being inserted into PS_PAY_ACK_STG_PUB.
Inserting Bad Earnings SQL Into PS_PAY_ACK_STG_PUB Example of SQL for all valid records which pass all the data being inserted into PS_PAY_ACK_STG_PUB:
Inserting SQL Into PS_PAY_ACK_STG_PUB PeopleCode to check if any records were written to the staging tables was added in section CHECKACK, step01. This would perform a rollback, Exit(1) if no staging table data was found or a commit, Exit(0) if staging table data to be published was found.
SQLExec("SELECT 'X' FROM PS_PAY_ACK_STG_PUB", &PUB_EXIST); If &PUB_EXIST <> "X" Then Exit (0); Else Exit (1);
End-If;
After CHECKACK, the section PUB_SEC in program PY_BATCHPUB was added to perform the check for active Publish Rules for the Program name, to retrieve the Job Instance, to insert the Batch Parameter trigger table for the Batch Publish program, and call the Batch Publish program.
Section PUB_SEC in PY_BATCHPUB AE Program Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) The include files 'stdapi.sqc', 'eoprcsnm.sqc', 'eoactive.sqc', 'eoparam.sqc' were added into the batch program PAYGL01.SQR.
#Include 'stdapi.sqc' #Include 'payrnctl.sqc' #Include 'tranctrl.sqc' #Include 'stderror.sqc' #Include 'sqlerr.sqc' #Include 'eoprcsnm.sqc' #Include 'eoactive.sqc'
#Include 'eoparam.sqc' for Batch Publish
!Update Process API !Get-Run-Control procedure !Transaction control (commits, etc.) !Routine for error display !SQL Error Handling Procedure !Determine Process Name !Determine Active Publish Definition
!Insert values into Parameter Table
Logic was added to the PAYGL01.SQR to get the process instance in procedure 'Get-Run-Control-Parms' by calling 'Stdapi-Init' whose logic is declared in the 'stdapi.sqc' include file.
!*************************** begin-procedure Init-Report !*************************** move 'Payroll GL Interface' to $ReportTitle do Init-DateTime
Page 124 of 136
do Init-Number do Stdapi-Init do Initialization move 'N' to $CyclePrompts PAYINIT do Payroll-Report-Initialization
end-procedure
!Don't prompt for On/Off cycle in
Logic was added to PAYGL01.SQR to get the process name by calling 'Get-Process-Name' and to get a count of active Publish Rules for the Process Name by calling 'Get-Active-In-BatchPub' (contained in 'eoprcsnm.sqc' and 'eoactive.sqc' include files). If there are active Publish Rules, then a call to 'Insert-Param-In-BatchPub' procedure ('eoparam.sqc') will insert a record into the trigger table for the Batch Publish program. A call to 'Get-Job-Instance' ('stdapi.sqc') is also needed as the job instance must be passed to 'Insert-Param-In-BatchPub' as the Batch Publish program will use the Job Instance to find the Batch Parameter record created by this run.
!****************************** begin-procedure Initialization !****************************** do Get-Current-DateTime do Build-Array do Initialize-Array move $AsOfToday to $Journal_Line_Date move 0 to #Total_Acctg_Lines move 0 to #Msg !------------------------Start Set Up EIP ----------------------------------------do Get-Process-Name (#prcs_process_instance, $prcsname) do Get-Active-In-BatchPub ($prcsname, #cntmsg) if #cntmsg > 0 do Get-Job-Instance do Insert-Param-In-BatchPub (#prcs_process_instance, #prcs_job_instance, $prcsname, ime) end-if !-------------------------end-procedure
$SysDateT
End Set Up EIP
-------------------------------------------
Using SQL to screen out PROCESS_INSTANCE = 0 on the select statement before inserting to the staging tables was not necessary as staging tables, not application tables, were being used. Logic was added to insert data to the staging table PY_PAY_ISS_STG_PUB and set fields AUDIT_ACTN and PROCESS_INSTANCE. Using IN_PROCESS_FLG was not necessary as we are not locking any tables up as we publish from the staging tables rather than the application tables.
!*********************************** begin-procedure Write-Payment-Issued !*********************************** Begin-SQL ON-ERROR=SQL-error INSERT INTO PS_PAY_ISS_STG_PUB (EMPLID, EMPL_RCD, EX_DOC_ID,
Page 125 of 136
EX_DOC_TYPE, EX_LINE_NBR, MONETARY_AMOUNT, CURRENCY_CD, PAYCHECK_STATUS, PAYCHECK_NBR, CHECK_DT, FORM_ID, ACCOUNT, AUDIT_ACTN, PROCESS_INSTANCE ) VALUES ($Emplid, #Empl_Rcd, $Ex_Doc_Id, $Ex_Doc_Type, #Ex_Line_Nbr, #Monetary_Amount, $Ex_Currency, $Check_Status, #Check_Iss_Nbr, $Check_Dt, $FormId, $Account, 'A', #Prcs_Process_Instance ); End-SQL
end-procedure
! contains Check #
Activit y 8 Create Automated Publish Job Definition

If using an Automated Publish Job Defintion: Run Mode must be Serial. Add AE Publish program EOP_PUBLISHA after the application batch process.
Job Definition of BATCHPUB Job
Job Definition Options for BATCHPUB Job Note. Jobs are not supported on the client; jobs require the scheduling support that only a server environment can offer. Also, only EIP aware processes are allowed in Job Definitions. All processes within a job request notify the server of the run status when they complete. This is how the decision is made to continue with the next job process. Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program)
Page 126 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM The Batch Publish program EOL_PUBLISH was called as the last step in the new AE PY_EXPVALIDT program so it is unnecessary to set up a job to perform the Batch Publish step. Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) A new menu item Payment Notification was created in Compensate Employees, Manage Payroll Process(US) and Manage Payment Process(CAN), Payment Notification to do a manual Batch Publish (EOP_PUBLISM) after all Payroll processes are done.
Payment Notification Batch Process
Activit y 9 Create Manual Publish Run Control

If using a manual Publish Run control: Process Frequency Once - AE Publish program will process request, frequency will be modified to Don't Run when process is complete. Always - AE Publish program will process request, frequency will not be modified. Don't Run - AE Publish program will NOT process. Request ID Unique Identifier. Process Name COBOL, SQR or Batch application name. The AE Publish program will use this field to read EO_MSGBATPRM for the PROCESS_INSTANCE.
Manual Batch Publish Run Control
Manual Batch Publish Process Scheduler Request
Activit y 10 Test Topics

Create your 'Test Message' Run your Batch Publish Create your 'Test Message' Use this to see if your message is defined properly and can be published, without using your Batch Publish logic. In 2 or 3 tier, in the Application Designer, open the message definition, highlight version1, right click and choose 'Create Test Message' to access the 'Test Message' dialog box which will display all the record and fields that make up the message and allow data to be input into the message. Use the Message Monitor to examine the contents of the message and that it contains all the record and field data you wish to expose to the outside world Run your Batch Publish Option 1: Run your Application Program and follow that by running the Batch Publish program as two separate Process Instance Steps.
Page 127 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Option 2: Run your Application Program followed by running the Batch Publish program as two steps within the same Job Instance.
Tips and Techniques

If you are going to do deletes, be sure to use staging tables. The PeopleSoft generic Batch Publish program should meet your development needs. If it does not, you'll need to write your own publishing program and include the same message chunking/routing logic and ability to produce either a message or a flat file within your program that are found in the Batch Publish program. Try to structure your program so a minimum number of cursors are opened. There can be multiple transactions in a Message. Placing multiple transactions in a message is more efficient than publishing one transaction per message. Always place multiple transactions in a message when publishing from batch. Logic should be added before flagging the record for publication or to insert to a staging table or tickler record to check: That the message is active. This is an optional check. If the message is being published for a specific Business Unit or Setid then the Business Unit or Setid must have the ability to publish the message. For the WMS example, if only 4 Business Units are online with using App Messaging to PeopleSoft, and the other 350 Business Units are not, only those 4 Business Units should generate a message. PeopleSoft has provided a centralized table and component where application groups can log which Business Units or Setids can publish a particular message. A PeopleCode function, COBOL or SQR routine that inquires against the table and returns whether the Message can be published for the Setid or Business Unit passed as a parameter is also provided. This is an optional check. Note. This logic would needed to be added within the application's batch program to prevent any logic to flag the records for publication, or insert data into a staging or tickler table for later publication. Before publishing any messages, the AE publisher supplied by PeopleSoft will check if all the Batch Publish Control and Routing tables have been set up properly, and should cause an error message and abort if it returns with a non-zero value. The user should be prevented from running the program if the routine returns an error because the message published will not be able to be routed properly, causing problems in the message processing downstream. This is an incremental message and should generate a message in the base language of the publishing system.
For more information about base language, see Integration Tools and Techniques: Introducing Related Language. The purpose of the In Process Flag and the Process Instance being on the flagged application table record is to prevent other processes from updating the record before its data has been published as a message. To prevent this from happening, all on-line programs and batch programs that can change or delete the flagged application data must be modified to disable the selection of data where a non-zero Process Instance or non-zero In Process Flag is found. If this check is not in place then the following could happen: Scenario 1 A batch program could change data from A to B, and the message to be published should say B. However, an on-line program changes the data back from B to A, and publishes a message of A. If the AE generic publish program did not run in time, the background program grabs the data and it now says A. So, A message is published twice and B message is never published. Depending on the application, the fact that value was once B may be important. Scenario 2 The batch program does an add. Before the batch job does a publish the transaction is modified online and the component publishes the change record. For some processes, adding a check against the In Process Flag and Process Instance may not be necessary (for example, Payroll Acknowledgement or Payment Issued programs see use cases above).
Page 128 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM It's your responsibility to identify other programs that may update the flagged application tables and modify them to prevent the flagged data from changing before the Publish program has been run. The generic Batch Publish program should be set up to run immediately after the application program to prevent a time lag before the message is published and to release the row lock as quickly as possible. Circular publishes. Circular publishes are when data added or modified through an inbound message subscription, in turn publishes the data back out to other nodes, including the node that originally sent the first message. This only happens if the business object you are dealing with for the Batch Publish process also has an incremental or full message subscription. If you have this case, you must 1) trap the PubNodeName within the message subscription and 2) set the message attribute DoNotPubToNodeName prior to calling the Publish() function. This will publish the message out to all nodes expecting the message except the one contained in the DoNotPubToNodeName value. Make sure the logic in bold below is added where appropriate. Within the message subscription add the following to trap the originating node name:
PanelGroup string &PUBNODENAME; ... &PUBNODENAME = &MSG.PubNodeName;
...
You will need to save the &PUBNODENAME as a field on one of the inbound staging tables if an application program is later used to validate, insert/modify and publish the new data later down the line. Within the publish logic, if done from on-line Panel Group or record, add the following to make sure the message publishes to all subscribing nodes except the one that originated the business component message:
PanelGroup string &PUBNODENAME; ... &MSG = CreateMessage(Message.UOM_SYNC); If &MSG.IsActive Then &RS0 = GetLevel0(); &MSG.CopyRowsetDelta(&RS0); &PUBNODENAME; &MSG.DoNotPubToNodeName = &PUBNODENAME; &MSG.Publish();
End-If;
If the publish logic is done via the Batch Publish program, as is the case with Batch Publish and EDI Outbound Conversion design patterns, allow the circular message to be published back to the node from where the message originated. However, add a field on the message to save the originating node's name. When this message is published back to the originating node, OnRouteSubscribe logic is added to the channel to screen out messages where the originating node for the message is the node that we are currently on. The message will be sent to all appropriate nodes, however the originating node won't process it.
Frequently Asked Questions

1. How do I avoid splitting a logical unit of work across messages? When a logical unit of work has multiple levels - parent, child, and grandchild, for example - we don't want to publish the parent in one message and the child in another. Our approach is to add an entire LUW to a message, then check the %MaxMessageSize parameter. If the message exceeds the limit, we publish it and create a new one to hold subsequent transactions. With this method we might exceed the MaxMessageSize, but only by one transaction. 2. What about the risk of publishing false positives from a set processing application? The possibility of including false positives in a message is inherent to set processing. Data that wasn't really changed may get published. It's possible that a row affected by the set-based application was not changed at all, if a field was updated with the value it already contained. Panel Processor takes care of this online by comparing the before and after images in the buffers, but there's no easy way to do this in set
Page 129 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM processing.. You can write SQL in a way that reduces the number of false positives. Generally, the likelihood of publishing unchanged data occasionally is small. 3. Why do we have to worry about audit action values? The messages we publish from batch need to be indistinguishable from those we publish from online, so we have to insert the same audit action values in our batch messages as Panel Processor does for online messages. 4. What about performance? The Application Messaging architecture is designed to be streamlined and simple, and as an App Server process so it's scalable (by adding Message Brokers and/or App Servers). Preliminary findings show that producing a message is as fast as producing a file, while a message is more seamless to the user. 5. What about concurrent processing? The Parameter table is keyed to allow multiple jobs to be processing different sets of data at the same time. The use of the Process Instance keeps these jobs from stepping on each other. 6. If the AE program uses dedicated temp tables to support parallel processing, will the generic AE subscriber still know which physical tables contain the data? Yes. This is handled under the covers by AE and requires only that the generic publishing program use %TABLE() when referencing record names. 7. Does the Batch Publish design pattern handle 'deletes'? Yes, through the use of staging tables. If you have to publish information about deleting rows of data, you must use staging tables as your source tables. 8. If multiple tables are involved in the batch program that needs to be published, which tables need audit action? All tables needed for the publish message need to contain the appropriate 'add' or 'change' audit action and process instance fields and be inserted to the Parameter table. 9. Is there a way to publish in "set" from a table or set of tables? No. Each row in the Message Object rowset must be populated row by row from the Fetches on the Record Object.
PeopleSoft 8 Enterprise Integration PeopleBook
Copyright 2000 PeopleSoft, Inc. All Rights Reserved.
Page 130 of 136
Appendix E Integration Broker Troubleshooting

Integration Broker Troubleshooting
This chapter includes some basic troubleshooting techniques and is for reference only.
Publication Contract not created

Possible causes: 1. 2. No publication PeopleCode exists. Publication PeopleCode is incorrect.
Publication Contract stays in NEW status

Possible causes: 1. 2. 3. 4. 5. 6. 7. Message Queue is paused. Publication Dispatcher has crashed or has been brought down. Node should be Active. Previous message had a status of Retry, Error, or Timeout. Domain is not active. Incorrect Gateway URL defined on Message Node. After unsuccessful ping, a row may be added to the table PSNODESDOWN; which will hold up the message queue. Query the table PSNODESDOWN.
Publication Contract stays in RETRY status

Possible causes: 1. 2. The remote node cannot be pinged successfully. The publication contract will be processed when the remote node comes back up. No publication handler available, either because its crashed or its been brought down.
Publication Contract stays in WORKING status

Possible causes: 1. 2. The publication handler processing the contract is on another machine and either the machine or the domain is down. Processing should continue when the pub/sub system on the other machine comes back up. Single threading on the application server is making things slow.
Publication Contract is in T IMEOUT status

Possible causes: 1. 2. 3. 4. 5. Transaction is not setup on the target node definition. Check APPSRV.LOG file for possible cause. Subscribing Node should be Active. Message Node URL is incorrect in the integrationGateway.properties file. No subscription PeopleCode exists on the subscribing system, or subscription PeopleCode is incorrect. An exception occurred on the target application server (look in APPSRV.LOG file for details) verify the following: a. Source node defined in target database. b. Verify correct password on node, target and source (if using password). c. Message or Channel not defined in target database. d. Incorrectly routed reply. Check Gateway for correct machine address or target node. e. No target local node defined. Page 131 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM f. Bad XML syntax.
Publication Contract is in ERROR status

Possible causes: 1. 2. Message Node URL is incorrect. Subscription PeopleCode is bad.
Subscription Contract not created

Possible causes: 1. 2. Message subscription is inactive. Queue routing rule not set up properly.
Subscription Contract stays in NEW status

Possible causes: 1. 2. 3. 4. 5. 6. 7. 8. 9. Application Server down. Pub/Sub process not configures on the Application Server domain. The Subscription Dispatcher has crashed or has been brought down. Message definition not active. Subscription PeopleCode is not active. Message queue is paused. Node is paused. Previous message had errors or timed out. No row was inserted into PSAPMSGSUBPRCID. To insert a row enter the following SQL statement: Insert into PSAPMSGSUBPRCID values(0)
Subscription Contract stays in STARTED status

Possible causes: 1. 2. Subscription Handler down. Check the target component online to make sure they are valid.
Subscription Contract stays in WORKING status

Possible causes: 1. 2. No subscription PeopleCode exists. Subscription Handler crashed while processing message.
Subscription Contract is in ERROR status

Possible causes: 1. 2. 3. 4. Message queue property if Ordered will allow subscription contracts to go in random order. This will cause FULLSYNC message to error out when the transaction as subscribed before the header. Subscription PeopleCode error. Application Data error. Verify auto-number sequence.
Subscription Contract is in EDIT status

Possible cause:
Page 132 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM 1. Message was edited and has yet to be resubmitted for processing.
Subscription Contract is in RETRY status

Possible causes: 1. 2. Subscription PeopleCode is empty. Message Definition on target in not active.
Cannot find message in Message Monitor

Possible causes: 1. 2. User does not have security for the message channel. The Service Operations Monitor criteria have filtered out the message.
Messages are being processed in an incorrect order

Possible cause: 1. The queue has been partitioned, and the resulting sub-channels do not match what was assumed for the ordering of the messages.
Message Instance not created

Possible cause: 1. Message is inactive.
Message Instance stays in NEW status.

Possible causes: 1. 2. 3. 4. The Application Server is down. Pub/Sub services not configured on Application Server domain. The Message Dispatcher has crashed or has been brought down. The item is not at the top of the queue. All messages with the same Channel/Sub-channel are in the same queue.
Message Instance stays in STARTED status.

Possible causes: 1. 2. All message Handlers have crashed or have been brought down. Processing will resume when Message Handlers come brought back up. The Message Dispatcher processing the message is on another machine, and either the machine or the application server domain is down.
Message Instance stays in WORKING status.

Possible causes: 1. 2. Message Broker Handler has crashed. The Message Handler working on the message is blocked. The service will time out, and the Message Dispatcher will retry the message.
M y Publish() PeopleCode finishes successfull y, but there is no message in the Message Monitor
Possible cause: 1. The message definition is inactive. Page 133 of 136
Unable to ping a node

Possible causes: 1. 2. 3. 4. The web server for the Gateway is down. The Gateway is not configured properly. The Application Server for the node is down. Verify URL is correct. Copy URL in browser address, should see:
5.
Also try to ping both machines using machine names. If that fail, use their IP-addresses instead.
Message Queue is PAUSED

Some message channels are delivered from PeopleSoft as paused. 1. Change the status to RUN in order for the messages to process from NEW to WORKING.
Page 134 of 136
Appendix F Validation and Feedback

This section documents the real-world validation that this Integration Guide has received.
CUSTOMER VALIDATION
PeopleSoft is working with PeopleSoft customers to get feedback and validation on this document. Lessons learned from these customer experiences will be posted here.
FIELD VALIDATION
Additional lessons learned from field experience will be posted here.
Page 135 of 136
Appendix G Revision History

Authors
PeopleSoft Enterprise Campus Solutions Development and Support Teams
Revision History
October 2010 - Created document. May 2011 Updated document to include Subscriber Only configuration steps. Added new Appendix D for Batch Publish Design Pattern instructions and examples.
Page 136 of 136

CS HCM Integration Person BioDemo Guide 05-31-2011

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CS HCM Integration Person BioDemo Guide 05-31-2011

Hochgeladen von

Copyright:

Verfügbare Formate

PeopleSoft Integration Reference Guide

Copyright Oracle USA 2010. All rights reserved.

Structure of this Document

Copyright Oracle USA 2010. All rights reserved.

Who Should Read This Guide?

Before You Begin

Copyright Oracle USA 2010. All rights reserved.

Copyright Oracle USA 2010. All rights reserved.

CHAPTER 3: CONFIGURING AND ADMINISTERING PEOPLESOFT CS TO HCM INTEGRATIONS

Understanding PeopleSoft CS to HCM Person Bio-Demo Data Integrations

Administrative Tasks for CS HCM Person Bio-Demo Data Integrations

Copyright Oracle USA 2010. All rights reserved.

Task Configure Integration Broker messaging

System CS 9.0 HCM 9.0/9.1

Tool Required Integration Broker

Run full synch setup data messaging

CS 9.0 HCM 9.0/9.1

Enterprise Component Full Data Publish

Run full synch transaction data messaging

CS 9.0 HCM 9.0/9.1

Enterprise Component Full Data Publish

Validate data load in Integration Broker environment

CS 9.0 or HCM 9.0/9.1

Online access or online query Online access

Configure Portal Navigations

CS 9.0 or HCM 9.0/9.1

CS 9.0 or HCM 9.0/9.1

Ongoing data sync (updates)

CS 9.0 or HCM 9.0/9.1

Loading the Setup Data

Copyright Oracle USA 2010. All rights reserved.

Defining Integration Definitions

Setup Data Loading Sequence

Integration Name COUNTRY_FULLSYNC CURRENCY_FULLSYNC STATE_FULLSYNC SETID_INITIALIZE TBLSET_CONTROL_INITIALIZE

Copyright Oracle USA 2010. All rights reserved.

Manual Entry Data Load

Transactional Data Loading Sequence

Copyright Oracle USA 2010. All rights reserved.

Person Transaction Data Campus Solutions 9.0 to HCM

Integration Name PERSON_BASIC_FULLSYNC.VERSION_4

Copyright Oracle USA 2010. All rights reserved.

CITIZENSHIP CITIZEN_PSSPRT VISA_PMT_DATA VISA_PMT_SUPPRT

Copyright Oracle USA 2010. All rights reserved.

Configuring and Administering CS HCM Person Bio-Demo Data integrations

PERSON_DATA PERSON_DATA PERSON_DATA

Copyright Oracle USA 2010. All rights reserved.

Resolution 835279 Resolution 837657

HR 9.1 Bundle #3 on 10/01/2010

Resolution 834256 Resolution 837135

HR 9.0 Bundle #14 on 10/15/2010

Copyright Oracle USA 2010. All rights reserved.

Configuring Integration Broker Gateways and Nodes

Configuring FullS yn c Service Operations

Configuring Incremental S ync Services

Configuring PERSON_BAS IC_SYNC

Copyright Oracle USA 2010. All rights reserved.

Figure 1 PERSON_BASIC_SYNC Web Serivce Access

2. Activate Service Operation(s) and Create Routing(s) in CS 9.0:

Copyright Oracle USA 2010. All rights reserved.

Figure 2 PERSON_BASIC_SYNC Service Operation

Copyright Oracle USA 2010. All rights reserved.

Figure 3 PERSON_BASIC_SYNC Routings

Figure 4 PERSON_BASIC_SYNC Routing Definition