CS HCM Integration Person BioDemo Guide 05-31-2011

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 Integration Reference Guide

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.

© Copyright Oracle USA 2010. All rights reserved. of 136

TABLE OF CONTENTS

Table of Contents 3

Chapter 1 - Introduction 4 Structure of this Document 4 Related Materials 4

Chapter 2 - Overview 5 Introduction 5 Who Should Read This Guide? 5 Before You Begin 5 Common Terms 6

Chapter 3: Configuring and Administering PeopleSoft CS to HCM Integrations 7 Understanding PeopleSoft CS to HCM Person Bio-Demo Data Integrations 7 Loading the Setup Data 8 Configuring and Administering CS – HCM Person Bio-Demo Data integrations 14

Chapter 4: Understanding Business Process Impacts in owner/subscriber integration 31 Configuring the Last Employee ID Assigned Number 35

APPENDIX A – CONFIGURING INTEGRATION BROKER GATEWAYS AND NODES 36

APPENDIX B - CONFIGURING FULLSYNC SERVICE OPERATIONS 41

APPENDIX C – FULLSYNC AND SYNC SERVICE OPERATIONS INCLUDED FIELDS 55

APPENDIX D– BATCH PUBLISH DESIGN PATTERN 110 Developer Activities 114 Tips and Techniques 128 Frequently Asked Questions 129

APPENDIX E– INTEGRATION BROKER TROUBLESHOOTING 131 Integration Broker Troubleshooting 131

APPENDIX F – VALIDATION AND FEEDBACK 135

Customer Validation 135

Field Validation 135

APPENDIX G – REVISION HISTORY 136 Authors 136 Revision History 136


Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM

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 PeopleSoft’s 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



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 organization’s 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.



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 Definition

CS Campus Solutions product suite.

HCM Human Capital Management product suite.

EIP Enterprise Integration Point. These include Fullsync and incremental Sync

service operations.

Owner Another term for System of Record; the system that publishes data to a

subscribing system in synchronization services.

SOR System of Record; the system that publishes data to a subscribing system in

synchronization services data loads.

User Profiles 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.



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.

Administrat ive 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.



Task Phase System Tool

Required

Comments

Configure Integration

Broker messaging

Implementation CS 9.0

HCM

9.0/9.1

Integration

Broker

Configure remote gateway. Add integration nodes

for Integration Broker environment.

Configure FullSync and Sync Setup Data service

integrations.

Run full synch setup data

messaging


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.

Run full synch

transaction data

messaging


HCM

9.0/9.1

Enterprise

Component

Full Data

Publish


configured.

Fullsync data loads should follow the

Transactional Data Loading Sequence as defined

later in this document.

Validate data load in

Integration Broker

environment


or

HCM

9.0/9.1

Online

access or

online

query

In event of data errors, use online pages, reports,

and queries to validate the data. Rerun full synch

process as necessary.

Configure Portal

Navigations


or

HCM

9.0/9.1

Online

access

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


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.



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 Synchronization

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.



Integration Description Integration Name Table(s)

Country Codes COUNTRY_FULLSYNC

COUNTRY_TBL

Currency Codes CURRENCY_FULLSYNC

CURRENCY_CD_TBL

State/Province Codes STATE_FULLSYNC

STATE_TBL

SetIDs SETID_INITIALIZE SETID_TBL

Tableset Controls TBLSET_CONTROL_INITIALIZE SET_CNTRL_TBL

SET_CNTRL_GROUP

SET_CNTRL_REC

Regulatory Regions REGULATORY_REGION_FULLSYNC REG_REGION_TBL

HR Business Units BUS_UNIT_HR_FULLSYNC BUS_UNIT_TBL_HR

Company Codes COMPANY_FULLSYNC COMPANY_TBL

Location Codes LOCATION_FULLSYNC LOCATION_TBL

Department Codes DEPT_FULLSYNC DEPT_TBL

Job Codes JOBCODE_FULLSYNC JOBCODE_TBL

Holiday Date Schedules HOLIDAY_DATE_FULLSYNC HOLIDAY_TBL

HOLIDAY_DATE

National ID Types NID_TYPE_FULLSYNC NID_TYPE_TBL

Name Types NAME_TYPE_FULLSYNC NAME_TYPE_TBL

Name Prefixes NAME_PREFIX_SUFFIX_FULLSYNC1 NAME_PREFIX_TBL

Name Suffixes NAME_PREFIX_SUFFIX_FULLSYNC2 NAME_SUFFIX_TBL

Name Royal Prefixes NAME_PREFIX_SUFFIX_FULLSYNC3 NM_ROYPREF_TBL

Name Royal Suffixes NAME_PREFIX_SUFFIX_FULLSYNC4 NM_ROYSUFF_TBL

Name Titles TITLE_FULLSYNC TITLE_TBL

Address Types ADDRESS_TYPE_FULLSYNC ADDRESS_TYP_TBL

Person of Interest Types POI_TYPE_TBL_FULLSYNC POI_TYPE_TBL

Ethnic Group Codes ETHNIC_GRP_FULLSYNC ETHNIC_GROUP_TBL

US Standard Occupational

Codes (USA)

US_SOC_FULLSYNC US_SOC_TBL

Supporting Documents

(Visa/Permits)

SUPPORT_DOC_FULLSYNC SUPPORT_DOC_TBL

Visa Permit Types VISA_PERMIT_FULLSYNC VISA_PERMIT_TBL,

VISA_PERMIT_SUP

Major Codes COMPETENCY_FULLSYNC3 MAJOR_TBL Table 1 Setup Data Integrations



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 Synchronization

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.



Person Transaction Data Campus Solutions 9.0 to HCM

Integration Name HCM Table

PERSON_BASIC_FULLSYNC.VERSION_4

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

PERSON_DISABILITY_FULLSYNC.VERSION_2

DISABILITY

ACCOM_REQUEST

DISABILITY_FRA*

DISABILITY_GER*

DISABILITY_CHE*

DISABILITY_ESP*

DISABILITY_BRA*

DISABILITY_NLD*

DISABILITY_NZL*



Integration Name HCM Table






PERSON_DIVERSITY_FULLSYNC.VERSION_2 DIVERSITY

DIVERS_ETHNIC

DIVERS_RELIGION*






PERSON_VISA_CITIZEN_FULLSYNC1.VERSION_1 CITIZENSHIP

CITIZEN_PSSPRT

PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1 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



Configuring and Administering CS – HCM Person Bio-Demo Data integrations

FullSync and Sync 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 Queue Subscription Handler App Package

PERS_POI_FULLSYNC.VERSION_1 PERSON_DATA PersPoiFullSync

PERSPOIFULLSYNC/PersPoiFullSync/OnNotify

PERS_POI_SYNC.VERSION_1 PERSON_DATA PersPoiSync

PERSPOISYNC/PersPoiSync/OnNotify

PERSON_BASIC_FULLSYNC.VERSION_4 PERSON_DATA PersonBasicFullsync

PERSON_BASIC_FULLSYNC/PersonBasicFullSync/OnNotify

PERSON_BASIC_SYNC.VERSION_4 PERSON_DATA SCC_HR_PERSON

SCC_HR_PERSON/PersonBasicSync/OnNotify

PERSON_DISABILITY_FULLSYNC.VERSI

ON_2

PERSON_DATA ONNOTIFY

PERSON_DISABILITY_FULLSYNC/PersonDisabilityFullsync/OnNoti

fy

PERSON_DISABILITY_SYNC.VERISON_2 PERSON_DATA ONNOTIFY

PERSON_DISABILITY_SYNC/PersonDisabilitySync/OnNotify

PERSON_DIVERSITY_FULLSYNC.VERSIO

N_2

PERSON_DATA PersonDiversityFullSync

PERSON_DIVERSITY_FULLSYNC/PersonDiversityFullsync/OnNotif

y

PERSON_DIVERSITY_SYNC.VERSION_2 PERSON_DATA PersonDiversitySync

PERSON_DIVERSITY_SYNC/PersonDiversitySync/OnNotify

PERSON_VISA_CITIZEN_FULLSYNC1.VE

RSION_1


PERSON_VISA_CITIZEN_FULLSYNC1/PersonVisaCitizenFullSync1

/OnNotify

PERSON_VISA_CITIZEN_FULLSYNC2.VE

RSION_1


PERSON_VISA_CITIZEN_FULLSYNC2/PersonVisaCitizenFullSync2

/OnNotify

PERSON_VISA_CITIZEN_SYNC.VERSION_

1


PERSON_VISA_CITIZEN_SYNC/PersonVisaCitizenSync/OnNotify

WORKFORCE_FULLSYNC.VERSION_3 PERSON_DATA WorkforceFullSync

WORKFORCE_FULLSYNC/WorkforceFullSync/OnNotify

WORKFORCE_SYNC.VERSION_3 PERSON_DATA WorkforceSync

WORKFORCE_SYNC/WorkforceSync/OnNotify

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.



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 Transform

Program 1

Message.ver out of Transforms

PERSON_BASIC_SYNC.INTERNAL PDATA_SYNCV1 PERSON_BASIC_SYNC.VERSION_1

PERSON_BASIC_SYNC.INTERNAL PDATA_SYNCV2 PERSON_BASIC_SYNC.VERSION_2

PERSON_BASIC_SYNC.INTERNAL HMTF_TR_OA PERSON_BASIC_SYNC.VERSION_3

PERSON_BASIC_SYNC.INTERNAL HMTF_TR_OA PERSON_BASIC_SYNC.VERSION_4

PERSON_BASIC_FULLSYNC.INTERNAL PDATA_FULLV1 PERSON_BASIC_FULLSYNC.VERSION_1

PERSON_BASIC_FULLSYNC.INTERNAL PDATA_FULLV2 PERSON_BASIC_FULLSYNC.VERSION_2

PERSON_BASIC_FULLSYNC.INTERNAL HMTF_TR_OA PERSON_BASIC_FULLSYNC.VERSION_3

PERSON_BASIC_FULLSYNC.INTERNAL HMTF_TR_OA PERSON_BASIC_FULLSYNC.VERSION_4

PERSON_DIVERSITY_SYNC.INTERNAL HCM_MSG_XFR

M

PERSON_DIVERSITY_SYNC.VERSION_1

PERSON_DIVERSITY_SYNC.INTERNAL HMTF_TR_OA PERSON_DIVERSITY_SYNC.VERSION_2

PERSON_DIVERSITY_FULLSYNC.INTERNA

L

HCM_MSG_XFR

M

PERSON_DIVERSITY_FULLSYNC.VERSION_

1

PERSON_DIVERSITY_FULLSYNC.INTERNA

L

HMTF_TR_OA PERSON_DIVERSITY_FULLSYNC.VERSION_

2

WORKFORCE_SYNC.INTERNAL WORK_SYNCV1 WORKFORCE_SYNC.VERSION_1

WORKFORCE_SYNC.INTERNAL HMTF_TR_OA WORKFORCE_SYNC.VERSION_2



WORKFORCE_FULLSYNC.INTERNAL WORK_FULL_V1 WORKFORCE_FULLSYNC.VERSION_1

WORKFORCE_FULLSYNC.INTERNAL HMTF_TR_OA WORKFORCE_FULLSYNC.VERSION_2



The new messages have been delivered in the following resolutions and bundles:

Release 9.1

PERSON_BASIC_SYNC/FULLSYNC and

PERSON_DIVERSITY_SYNC/FULLSYNC Resolution 835279

HR 9.1 Bundle #3 on 10/01/2010 WORKFORCE_SYNC Resolution 837657

Release 9.0

PERSON_BASIC_SYNC/FULLSYNC and

PERSON_DIVERSITY_SYNC/FULLSYNC Resolution 834256 HR 9.0 Bundle #14 on

10/15/2010 WORKFORCE_SYNC Resolution 837135



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 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 integration you will use.

Please refer to Appendix B for standard Fullsync configuration steps.

Configuring Incremental Sync 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_BASIC_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. Go to PeopleTools > Permissions & Roles > Permission Lists.

b. Select the relevant permission list from the search dialog box.

c. Go to the “Web Services” tab.

d. Enter the corresponding Service(s) for the Service Operation(s) you wish to use..

e. 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 1 PERSON_BASIC_SYNC Web Serivce Access

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

a. Go to PeopleTools > Integration Broker > Integration Setup > Service Operations.

b. Select PERSON_BASIC_SYNC from the search dialog box.

c. Check the “Active” check box on the “General” tab.

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



Figure 2 PERSON_BASIC_SYNC Service Operation



Figure 3 PERSON_BASIC_SYNC Routings

Figure 4 PERSON_BASIC_SYNC Routing Definition



Figure 5 PERSON_BASIC_SYNC Routing Parameters

Figure 6 PERSON_BASIC_SYNC Routing Graphic



3. Activate Message Queue

p. Go to PeopleTools > Integration Broker > Service Operations Monitor > Administration > Queue Status.

q. Scroll down the page until you find the relevant PERSON_DATA Queue Name.

r. 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 user’s permission list.


b. Select the relevant permission list from the search dialog box (primary permission list for the user).


d. Enter the corresponding Service(s) for the Service Operation(s) you wish to leverage.


secondary page.

f. Click “OK” to return to the “Web Services” page.

g. Click “Save” to save the updated Permission List.



Figure 8 PERSON_BASIC_SYNC Service Permissions

2. Activate Service Operation(s) and Create Routing(s) and Subscription Handler in HCM 9.1:


b. Select PERSON_BASIC_SYNC from the search dialog box.


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


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.



Figure 9 HCM 9.1 PERSON_BASIC_SYNC Service Operation



Figure 10 HCM 9.1 PERSON_BASIC_SYNC Handlers

Figure 11 HCM 9.1 SCC_HR_PERSON Handler Details



Figure 12 HCM 9.1 PERSON_BASIC_SYNC Routings



Figure 13 HCM 9.1 PERSON_BASIC_SYNC Routing Definition



Figure 14 HCM 9.1 PERSON_BASIC_SYNC Routing Parameters



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 Description

cccmntpd.sqc Personal Data routines

cccupdnm.sqc Update name

cccgetad.sqc Get Student Address

cccgetnm.sqc Get Name

cccupdad.sqc Update Address

cccupdcs.sqc Update-Citizenship-Status

cccmsgct.sqc Reset SOA Batch Message Table Counters

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.



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



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.



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.



Figure 18 Example of hiring an employee

Figure 19 Example of hiring a contingent worker



Figure 20 Example of adding a Person of Interest

Figure 21 Example of adding an admissions applicant in CS



Figure 22 Example of hiring faculty

Figure 23 Example of loading batch data in CS



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



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. Set the Service Configuration in the HR 9.1 database

2. Configure the Gateway in the HR 9.1 database

3. Configure the default local node in the HR 9.1 database

4. Configure the HR Gateway in the CS H900P7R2 database.

5. Configure the CS node in the HR database

6. Configure the default LOCAL node in the CS database

7. Configure the HR node in the CS database

8. Configure the CS node in the HR database.

9. 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. Navigate: PeopleTools > Integration Broker > Configuration > Service Configuration.

b. Set Service Namespace = 'http://xmlns.oracle.com/Enterprise/HCM/services'.

c. Set Schema Namespace = 'http://xmlns.oracle.com/Enterprise/Tools/schemas'

d. Set Target Location =

‘http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector’

e. Set Service System Status = 'Production'.

4. Configure the Gateway in the HCM 9.1 database

a. Navigate: PeopleTools > Integration Broker > Configuration > Gateways.

b. Select Integration Gateway ID = 'LOCAL'

c. Set URL =

‘http://machinename:port/PSIGW/PeopleSoftServiceListeningConnector/SPLTHL91'

d. Click the 'Load Gateway Connectors' button. It should load 9 connectors.

e. Save.

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



b. Select the default local node.

c. Set Descr = 'HCM 9.1 Instance'.

d. Set Authentication Option = 'Password'.

e. Node Password = 'PS'.

f. Default User ID = 'PS'.

g. Click the 'Connectors' tab.

h. Use gateway ' LOCAL'.

i. Set Connector Id = 'PSFTTARGET'.

j. Click the Portal tab.

k. Set Tools Release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should be able to see

the tools release string.

l. Set Application Release = 'HCM 9.1'.

m. Set Content URI Text = ' http://machinename:port/psc/SPLTHL91'.

n. Set Portal URI Text = ' http://machinename:port/psp/SPLTHL91'.

o. Click the WS Security tab.

p. Set Authentication Token Type = 'none'.

q. Disable the 'encrypted' checkbox.

r. Click Save

6. Configure the HCM Gateway in the CS 9.0 database.

a. Navigate: PeopleTools > Integration Broker > Configuration > Gateways

b. Add a New Value

c. Integration Gateway ID = <Gateway Name for HCM 9.1>.

d. URL = ‘http://machinename:port/PSIGW/PeopleSoftListeningConnector/databasename'

e. Click the 'Load Gateway Connectors' button. It should load 9 connectors.

f. Save.

g. 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. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes.

b. Add Node = <Name of CS 9.0 Node>

c. Set Descr = ‘CS 9.0 Instance'.

d. Set Authentication Option = 'Password'.

e. Node Password = 'PS'

f. Default User ID = 'PS'



g. Click the 'Connectors' tab

h. Set Gateway = ' LOCAL'

i. Set Connector ID = 'PSFTTARGET'

j. Click the Portal tab

k. Set Tools Release = '8.50.xx’ (Note: by pressing the <CTL>+J keys, you should be able to see

the tools release string)

l. Set Application Release = 'CS 9.0'.

m. Set Content URI Text = 'http://machinename:port/psc/databasename'

n. Set Portal URI Text = 'http://machinename:port/psp/databasename'.



q. Disable the 'Encrypted' checkbox.

r. 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. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes

b. Select the default local node

c. Set Descr = ‘CS 9.0 Instance'.

d. Set Authentication Option = 'Password'




h. Select Gateway = <Gateway Name for HCM 9.1> (Note: this is not the local gateway.)



k. Set Tools Release = '8.50.xx. (Note: by pressing the <CTL>+J keys, you should be able to see

the tools release string.

l. Set Application Release = 'CS 9.0'.

m. Set Content URI Text = ' http://machinename:port/psc/databasename

n. Set Portal URI Text = ' http://machinename:port /psp/databasename



q. Disable the 'encrypted' checkbox.

r. Click Save.



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. Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes.

b. Add Node: <Name of HCM Node>

c. Set Descr = ‘HCM 9.1 Instance'

d. Set Authentication Option = 'Password'




h. Gateway ID = <Gateway Name for HCM 9.1> (Note: this is not the local gateway.)



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

l. Set Application Release = ‘HCM 9.1’

m. Set Content URI Text = ' http://machinename:port/psc/databasename’

n. Set Portal URI Text = ' http://machinename:port/psp/databasename’



q. Disable (turn off) the ‘Encrypted’ checkbox.

r. Click Save.

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


b. Select gateway 'LOCAL'.

c. Select the 'Gateway Setup Properties' link.

d. User ID = ‘administrator’

e. Password = ‘password’

f. Click OK.

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



h. Enter the appropriate User ID

i. Enter the appropriate Password

j. Set the tools release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should

k. be able to see the tools release string.)

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


b. Select gateway 'LOCAL'.

c. Select the 'Gateway Setup Properties' link.

d. User ID = ‘administrator’

e. Password = ‘password’

f. Click OK.

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

h. Enter the appropriate User ID

i. Enter the appropriate Password

j. Set the tools release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should

k. be able to see the tools release string.)

l. 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. Navigate: PeopleTools > Security > Security Objects > Single Signon.

b. 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. Navigate: PeopleTools > Integration Broker > Service Operations Monitor > Administration>

Node Status. Do this on each database.

b. For each node name, enter its name and click the 'Ping Node' button.

c. It should respond with 'Success'.



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:


b. Select the relevant permission list from the search dialog box.


d. Enter the corresponding Service(s) for the Service Operation(s) you wish to use..


secondary page by selecting the “Full Access” option for the “”Access” column.

Figure 25 Permission List Web Services Security



Figure 26 Web Service Permissions – Full Access

13. Activate Service Operation(s) and Create Routing(s):

q. Go to PeopleTools > Integration Broker > Integration Setup > Service Operations.

r. Select the relevant Service Operation(s) from the search dialog box.

s. Check the “Active” check box on the “General” tab.

t. Make note of the “Queue Name” field, as you will need to verify that the Queue is in the “Running” status later.

u. Click on the “Routings” tab and add a new routing for the Service Operation by entering a value in the “Routing




Figure 27 Service Operation Definition



Figure 28 Service Operations Routings

v. Enter a “Sender Node” and a “Receiver Node” on the “Routings Definition” page of the “Routings” component.

w. Verify that the “Active” check box is checked. x. Click the “Save” button at the bottom of the “Routings Definition” page to save the routing.

y. Click the “Return” button at the bottom of the “Routings Definition” page to return to the Service Operation setup

component.

z. Save the Service Operation by clicking the “Save” button at the bottom of any of the pages in the Service Operations

component.



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.



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 user’s permission list.


b. Select the relevant permission list from the search dialog box (primary permission list for the user).


d. Enter the corresponding Service(s) for the Service Operation(s) you wish to leverage.


secondary page.

f. Click “OK” to return to the “Web Services” page.

g. Click “Save” to save the updated Permission List.



Figure 31 Permission List Web Services Security

Figure 32 Web Services Permissions - Full Access

16. Activate Service Operation and Create Routing.




b. Select the relevant Service Operation(s) from the search dialog box.


d. 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. Click on the “Routings” tab and add a new routing for the Service Operation.

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 “Save” button at the bottom of the “Routings Definition” page to save the routing.

i. Click the “Return” button at the bottom of the “Routings Definition” page to return to the Service Operation setup

component.

j. Save the Service Operation by clicking the “Save” button at the bottom of any of the pages in the Service Operations

component.



Figure 34 Service Operation Routings

Figure 35 Routing Definitions

17. Activate or create the required Service Operations OnNotify handler.

a. Click on the “Handlers” tab of the Service Operations component.

b. Enter a Handler Name as shown below if one does not exist.

c. 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”)]



d. Set Type = “OnNotify”

e. Set Implementation = “Application Class”

f. Set Status = “Active”

g. Click on “Details” link

h. 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 ”)]

i. Set Path = “:”

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

k. Set Method = “OnNotify”

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



Figure 37 Handler Details

18. Activate Message Queue.

a. Go to PeopleTools > Integration Broker > Service Operations Monitor > Administration > Queue Status.

b. Scroll down the page until you find the relevant Queue Name (from the Service Operation setup page noted earlier).

c. Review the queue “Status” and activate the queue by pushing the “Run” button if needed.

Executing the Full Data Publish Utility

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. Enter the Message Name of the Service Operation

c. Enter a Publish Rule ID, a Description, and set the Status field to “Active”

d. Check the Create Message Header and Create Message Trailer check boxes.

e. Save the page.



Figure 38 Full Table Publish Rules

20. Execute the Full Data Publish Process

a. Go to Enterprise Components > Integration Definitions > Initiate Processes.

b. Create a new Run Control ID as shown below.

c. Enter a “Request ID”.

d. Select “Always” for the Process Frequency.

e. Enter the Message Name from the Full Table Publish Rule created earlier (example: COUNTRY_FULLSYNC).

f. Save the page and click the “Run” button.

g. Select the “Full Table Data Publish” process from the Process Scheduler Request page.

h. Verify the process ran successfully.



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.



Figure 41 Asynchronous Service Operations Monitor



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



Figure 42 PERSON_BASIC_FULLSYNC.VERSION_4



Figure 43 PERSON_BASIC_SYNC.VERSION_4

Figure 44 PERS_POI_FULLSYNC



Figure 45 PERS_POI_SYNC



Figure 46 PERSON_DISABILITY_FULLSYNC.VERSION_2



Figure 47 PERSON_DISABILITY_SYNC.VERSION_2



Figure 48 PERSON_DIVERSITY_FULLSYNC.VERSION_2



Figure 49 PERSON_DIVERSITY_SYNC



Figure 50 PERSON_VISA_CITIZEN_FULLSYNC.VERSION_1



Figure 51 PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1



Figure 52 PERSON_VISA_CITIZEN_SYNC.VERSION_2



Figure 53 WORKFORCE_FULLSYNC.VERSION_3



Figure 54 WORKFORCE_SYNC.VERSION_3



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



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.



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



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.



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

Activity 1 — Determine Batch Publish Process Method

Summary of considerations

• Automated Batch Publish Process (SQR)

o Need to create Job Definition

o Job can only run on Server

o Publish is done when batch application finishes



o Automated Batch Publish Process (AE)

o Publish is done as last step in application AE program

o No restrictions on where processes can run

o Manual Batch Publish Process

o Need to schedule the batch publish process

o No restrictions on where processes can run

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

Activity 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



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


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.


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.

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



� 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 application-

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


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


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

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




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


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

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


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


A new Publish Rule, PAY_ISSUED, is added that will publish the entire contents of the PAYMENT_EXPENSES_ISSUE message without chunking it.



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

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


The message PAYMENT_EXPENSES_ACKNOWLEDGE is not being chunked so we skip this step.


The message PAYMENT_EXPENSES_ISSUE is not being chunked so we skip this step.

Activity 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



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;PROCESS_INSTANCE=0;PROCESS_INSTANCE=0;PROCESS_INSTANCE=0;

Example of a modified Update:

UPDATE PS_APPL_TBL

SET FIELD_1='A',

FIELD_2=[$AsOfToday],

PROPROPROPROCESS_INSTANCE=#PROCESS_INSTANCE, CESS_INSTANCE=#PROCESS_INSTANCE, CESS_INSTANCE=#PROCESS_INSTANCE, CESS_INSTANCE=#PROCESS_INSTANCE,

AUDIT_ACTN='C' AUDIT_ACTN='C' AUDIT_ACTN='C' AUDIT_ACTN='C'


ITEM_ID='1234' AND




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, PROCESS_INSTANCE, PROCESS_INSTANCE, PROCESS_INSTANCE,

AUDIT_ACTNAUDIT_ACTNAUDIT_ACTNAUDIT_ACTN)

VALUES ('A', $AsOfToday, #PROCESS_INSTANCE, 'A' #PROCESS_INSTANCE, 'A' #PROCESS_INSTANCE, 'A' #PROCESS_INSTANCE, 'A'

Example of a modified Update:

UPDATE PS_APPL_TBL

SET FIELD_1='A',

FIELD_2=[$AsOfToday],

PROCESS_INSTANCE=#PROCESS_INSTANCE, PROCESS_INSTANCE=#PROCESS_INSTANCE, PROCESS_INSTANCE=#PROCESS_INSTANCE, PROCESS_INSTANCE=#PROCESS_INSTANCE,

AUDIT_ACTN='C' AUDIT_ACTN='C' AUDIT_ACTN='C' AUDIT_ACTN='C'


ITEM_ID='1234' AND


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_INSTANCEPROCESS_INSTANCEPROCESS_INSTANCEPROCESS_INSTANCE, GROUP_BU,

GROUP_ID, OPRID, ASSN_OPRID, BUSINESS_UNIT, GROUP_TYPE, BAL_STATUS, EDIT_STATUS,

POST_STATUS,... AUDIT_ACTNAUDIT_ACTNAUDIT_ACTNAUDIT_ACTN)

SELECT &BIND(PROCESS_INSTANCE),&BIND(PROCESS_INSTANCE),&BIND(PROCESS_INSTANCE),&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''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.



For AE programs:


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 Blank - No cleanup of source table data is done

o D - Published rows are deleted from the source table

o U - IN_PROCESS_FLG of published rows is set to "X"

o C - IN_PROCESS_FLG and AUDIT_ACTN of published rows is set to blanks and PROCESS_INSTANCE

is set to zero

4. 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 Blank - No cleanup of source table data is done

o D - Published rows are deleted from the source table

o U - IN_PROCESS_FLG of published rows is set to "X"

o C - IN_PROCESS_FLG and AUDIT_ACTN of published rows is set to blanks and PROCESS_INSTANCE

is set to zero

3. Call Insert-Param-In-BatchPub

The following table describes the parameters for this procedure:

Parameter Key Description

PROCESS_INSTANCE Yes 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 Yes 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.

PROCESS_NAME The name of the COBOL, SQR, or AE program. This field is the key to the control data used to structure the message.

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

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



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:


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


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 SET PROCESS_INSTANCE =

%Bind(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) SELECT PRCSINSTANCE , PRCSINSTANCE ,

JOBINSTANCE , PRCSNAME FROM PSPRCSRQST WHERE PRCSINSTANCE =

%Bind(PROCESS_INSTANCE)

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 =



%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


The include files 'stdapi.sqc', 'eoprcsnm.sqc', 'eoactive.sqc', 'eoparam.sqc' were added into the batch program PAYGL01.SQR.

#Include 'stdapi.sqc' !Update Process API

#Include 'payrnctl.sqc' !Get-Run-Control procedure

#Include 'tranctrl.sqc' !Transaction control (commits, etc.)

#Include 'stderror.sqc' !Routine for error display

#Include 'sqlerr.sqc' !SQL Error Handling Procedure

#Include 'eoprcsnm.sqc' !Determine Process Name

#Include 'eoactive.sqc' !Determine Active Publish Definition

#Include 'eoparam.sqc' !Insert values into Parameter Table

for Batch Publish

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



do Init-Number

do Stdapi-Init

do Initialization

move 'N' to $CyclePrompts !Don't prompt for On/Off cycle in

PAYINIT

do Payroll-Report-Initialization

end-procedure

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, $SysDateTime)

end-if

!-------------------------- End Set Up EIP

-------------------------------------------

end-procedure

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,



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, ! contains Check #

$Check_Dt,

$FormId,

$Account,

'A',

#Prcs_Process_Instance

);

End-SQL

end-procedure

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




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.


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

Activity 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

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



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



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; PanelGroup string &PUBNODENAME; PanelGroup string &PUBNODENAME; PanelGroup string &PUBNODENAME;

...

&PUBNODENAME = &MSG.PubNodeName;&PUBNODENAME = &MSG.PubNodeName;&PUBNODENAME = &MSG.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;PanelGroup string &PUBNODENAME;PanelGroup string &PUBNODENAME;PanelGroup string &PUBNODENAME;

...

&MSG = CreateMessage(Message.UOM_SYNC);

If &MSG.IsActive Then

&RS0 = GetLevel0();

&MSG.CopyRowsetDelta(&RS0);

&MSG.DoNotPubToNodeName = &PUBNODENAME&MSG.DoNotPubToNodeName = &PUBNODENAME&MSG.DoNotPubToNodeName = &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



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.



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. No publication PeopleCode exists.

2. Publication PeopleCode is incorrect.

Publication Contract stays in NEW status

Possible causes:

1. Message Queue is paused.

2. Publication Dispatcher has crashed or has been brought down.

3. Node should be Active.

4. Previous message had a status of Retry, Error, or Timeout.

5. Domain is not active.

6. Incorrect Gateway URL defined on Message Node.

7. 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. The remote node cannot be pinged successfully. The publication contract will be processed when the remote node

comes back up.

2. No publication handler available, either because it’s crashed or it’s been brought down.

Publication Contract stays in WORKING status

Possible causes:

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

2. Single threading on the application server is making things slow.

Publication Contract is in TIMEOUT status

Possible causes:

1. Transaction is not setup on the target node definition. Check APPSRV.LOG file for possible cause.

2. Subscribing Node should be Active.

3. Message Node URL is incorrect in the integrationGateway.properties file.

4. No subscription PeopleCode exists on the subscribing system, or subscription PeopleCode is incorrect.

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



f. Bad XML syntax.

Publication Contract is in ERROR status

Possible causes:

1. Message Node URL is incorrect.

2. Subscription PeopleCode is bad.

Subscription Contract not created

Possible causes:

1. Message subscription is inactive.

2. Queue routing rule not set up properly.

Subscription Contract stays in NEW status

Possible causes:

1. Application Server down.

2. Pub/Sub process not configures on the Application Server domain.

3. The Subscription Dispatcher has crashed or has been brought down.

4. Message definition not active.

5. Subscription PeopleCode is not active.

6. Message queue is paused.

7. Node is paused.

8. Previous message had errors or timed out.

9. 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. Subscription Handler down.

2. Check the target component online to make sure they are valid.

Subscription Contract stays in WORKING status

Possible causes:

1. No subscription PeopleCode exists.

2. Subscription Handler crashed while processing message.

Subscription Contract is in ERROR status

Possible causes:

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

2. Subscription PeopleCode error.

3. Application Data error.

4. Verify auto-number sequence.

Subscription Contract is in EDIT status

Possible cause:



1. Message was edited and has yet to be resubmitted for processing.

Subscription Contract is in RETRY status

Possible causes:

1. Subscription PeopleCode is empty.

2. Message Definition on target in not active.

Cannot find message in Message Monitor

Possible causes:

1. User does not have security for the message channel.

2. 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. The Application Server is down.

2. Pub/Sub services not configured on Application Server domain.

3. The Message Dispatcher has crashed or has been brought down.

4. 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. All message Handlers have crashed or have been brought down. Processing will resume when Message Handlers

come brought back up.

2. 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. Message Broker Handler has crashed.

2. The Message Handler working on the message is blocked. The service will time out, and the Message Dispatcher will

retry the message.

My Publish() PeopleCode finishes successfully, but there is no message in the Message

Monitor

Possible cause:

1. The message definition is inactive.



Unable to ping a node

Possible causes:

1. The web server for the Gateway is down.

2. The Gateway is not configured properly.

3. The Application Server for the node is down.

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



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.



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.

CS HCM Integration Person BioDemo Guide 05-31-2011

Documents

Transcript of CS HCM Integration Person BioDemo Guide 05-31-2011