Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
May 2011
Including: Overview of Campus Solutions 9.0 to HCM Integrations Step-by-Step of Implementation Activities Troubleshooting Tips and Techniques
PeopleSoft CS to HCM
Copyright 2010 Oracle, Inc. All rights reserved. Printed on Recycled Paper. Printed in the United States of America. Restricted Rights The information contained in this document is proprietary and confidential to PeopleSoft, Inc. Comments on this document can be submitted to Global Support Center. We encourage you provide feedback on this Integration Guide and will ensure that it is updated based on feedback received. When you send information to Oracle, you grant Oracle a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the express written permission of Oracle. This document is subject to change without notice, and Oracle does not warrant that the material contained in this document is error-free. If you find any problems with this document, please report them to PeopleSoft in writing. This material has not been submitted to any formal Oracle test and is published AS IS. It has not been the subject of rigorous review. Oracle assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. While each item may have been reviewed by Oracle for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk Information in this book was developed in conjunction with use of the product specified, and is limited in application to those specific hardware and software products and levels. Oracles may have patents or pending patent applications covering subject matter in this document. The furnishing of this document does not give you any license to these patents Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. PeopleSoft, PeopleTools, PS/nVision, PeopleCode, PeopleBooks, PeopleTalk, and Vantive are registered trademarks, and Pure Internet Architecture, Intelligent Context Manager, and The Real-Time Enterprise are trademarks of Oracle. All other company and product names may be trademarks of their respective owners. The information contained herein is subject to change without notice.
TABLE OF CONTENTS
Table of Contents Chapter 1 - Introduction Structure of this Document Related Materials Chapter 2 - Overview Introduction Who Should Read This Guide? Before You Begin Common Terms Chapter 3: Configuring and Administering PeopleSoft CS to HCM Integrations Understanding PeopleSoft CS to HCM Person Bio-Demo Data Integrations Loading the Setup Data Configuring and Administering CS HCM Person Bio-Demo Data integrations Chapter 4: Understanding Business Process Impacts in owner/subscriber integration Configuring the Last Employee ID Assigned Number APPENDIX A CONFIGURING INTEGRATION BROKER GATEWAYS AND NODES APPENDIX B - CONFIGURING FULLSYNC SERVICE OPERATIONS APPENDIX C FULLSYNC AND SYNC SERVICE OPERATIONS INCLUDED FIELDS APPENDIX D BATCH PUBLISH DESIGN PATTERN Developer Activities Tips and Techniques Frequently Asked Questions APPENDIX E INTEGRATION BROKER TROUBLESHOOTING Integration Broker Troubleshooting APPENDIX F VALIDATION AND FEEDBACK Customer Validation Field Validation APPENDIX G REVISION HISTORY Authors Revision History 3 4 4 4 5 5 5 5 6 7 7 8 14 31 35 36 41 55 110 114 128 129 131 131 135 135 135 136 136 136
Page 3 of 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. .
Related Materials
We recommend that before you read this guide, you also read the Campus Solutions-HCM Integration White Paper; it provides an overall summary of the objectives and various approaches to supporting separate CS and HCM instances. In addition to this document, additional implementation guides have been developed to assist you in understanding and implementing your CS HCM integrations. These documents and the Campus Solutions-HCM Integration White Paper are posted to My Oracle Support, associated with Feature Pack 4 Documentation (ID 1259484.1 ). Implementing Person Bio-Demo Data Integration between CS and HCM on My Oracle Support Implementing External Search/Match between CS and HCM on My Oracle Support Implementing CS Integration with the Higher Education Constituent Hub on My Oracle Support (Note that this document will not be released until late 2010 or early 2011) Implementing Portal Navigation Aggregation for CS and HCM Integration on My Oracle Support
This document is not a general introduction to Integration Broker and we assume that our readers are experienced IT professionals, with a good understanding of PeopleSofts Internet Architecture. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of system administration, basic Internet architecture, integration technologies, relational database concepts/SQL, and how to use PeopleSoft applications. This document is not intended to replace the documentation delivered with the PeopleTools 84x or 8.5x PeopleBooks. We recommend that before you read this document, you also read the PIA related information in the PeopleTools PeopleBooks to ensure that you have a well-rounded understanding of our PIA technology. Note: Much of the information in this document eventually gets incorporated into subsequent versions of the PeopleBooks. Many of the fundamental concepts related to PIA are discussed in the following PeopleSoft PeopleBooks: PeopleSoft Internet Architecture Administration (PeopleTools|Administration Tools|PeopleSoft Internet Architecture Administration) Application Designer (Development Tools|Application Designer) Application Messaging (Integration Tools|Application Messaging) PeopleCode (Development Tools|PeopleCode Reference) PeopleSoft Installation and Administration PeopleSoft Hardware and Software Requirements
Page 4 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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.
Page 5 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Some examples of the configuration tasks that you must perform for your CS to HCM Integrations include: Configuring the PeopleSoft CS and HCM installation and PeopleTools options tables. Setting up the integration gateway and integration nodes within the Integration Broker system. Activating services, service operations, and routings within the Integration Broker system. Defining roles and permissions for your user profiles.
Common Terms
This table provides definitions for some of the common terms that are used in this guide. Term CS HCM EIP Campus Solutions product suite. Human Capital Management product suite. Enterprise Integration Point. These include Fullsync and incremental Sync service operations. Another term for System of Record; the system that publishes data to a subscribing system in synchronization services. System of Record; the system that publishes data to a subscribing system in synchronization services data loads. User profiles define individual PeopleSoft users. You define user profiles and then link them to one or more roles. Typically, a user profile must be linked to at least one role to be a usable profile. The majority of the permissions that make up a user profile are inherited from the linked roles. Definition
Owner
SOR
User Profiles
Page 6 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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.
Page 7 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Phase Implementation
Comments Configure remote gateway. Add integration nodes for Integration Broker environment. Configure FullSync and Sync Setup Data service integrations.
Implementation
Assumes that Integration Broker is fully configured. For all owner/subscriber configurations, Setup data values should be populated in your subscribing target database before any person transactional data syncs are run. This is to ensure data integrity. Assumes that Integration Broker is fully configured. Fullsync data loads should follow the Transactional Data Loading Sequence as defined later in this document. In event of data errors, use online pages, reports, and queries to validate the data. Rerun full synch process as necessary.
Implementation
Implementation
Implementation
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
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).
Sustaining Support
Integration Broker
Assumes that Integration Broker is fully configured for Sync services, publishing from system of record to subscribing target system.
Page 8 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Note. For these setup data integrations, the data flow is one way only from your system of record to your subscribing target. To maintain data integrity in this one-way flow, much of the data loaded from your owner system should be hidden from view or made display-only in the subscribing target system. See the Implementing Portal Navigation between CS and HCM guide available on My Oracle Support for more details. You can use the following methods to load data from your system of record to the subscribing target system: Full Synchronization Services (full sync initial load only) Incremental Synchronization Services (sync)
No matter what method you use, you must load data in the proper sequence to accommodate data dependencies. The following section gives a high-level description of each method and provides the required table loading sequences.
Full S ynchronization
A full synchronization service (full sync) captures all of the data that you specify in the system of record (SOR) and publishes it to the subscribing system. It first deletes all data of the specified type that is in the subscriber and replaces it with the captured data. Warning! Because of the data deletion associated with full sync, consider running full sync only at implementation time or if you must clear your CS to HCM system and begin again. Use the full sync process for data that infrequently changes.
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.
Page 9 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Integration Description Country Codes Currency Codes State/Province Codes SetIDs Tableset Controls
Table(s) COUNTRY_TBL CURRENCY_CD_TBL STATE_TBL SETID_TBL SET_CNTRL_TBL SET_CNTRL_GROUP SET_CNTRL_REC REG_REGION_TBL BUS_UNIT_TBL_HR COMPANY_TBL LOCATION_TBL DEPT_TBL JOBCODE_TBL HOLIDAY_TBL HOLIDAY_DATE NID_TYPE_TBL NAME_TYPE_TBL NAME_PREFIX_TBL NAME_SUFFIX_TBL NM_ROYPREF_TBL NM_ROYSUFF_TBL TITLE_TBL ADDRESS_TYP_TBL POI_TYPE_TBL ETHNIC_GROUP_TBL US_SOC_TBL SUPPORT_DOC_TBL VISA_PERMIT_TBL, VISA_PERMIT_SUP MAJOR_TBL
Regulatory Regions HR Business Units Company Codes Location Codes Department Codes Job Codes Holiday Date Schedules National ID Types Name Types Name Prefixes Name Suffixes Name Royal Prefixes Name Royal Suffixes Name Titles Address Types Person of Interest Types Ethnic Group Codes US Standard Occupational Codes (USA) Supporting Documents (Visa/Permits) Visa Permit Types Major Codes Table 1 Setup Data Integrations
REGULATORY_REGION_FULLSYNC BUS_UNIT_HR_FULLSYNC COMPANY_FULLSYNC LOCATION_FULLSYNC DEPT_FULLSYNC JOBCODE_FULLSYNC HOLIDAY_DATE_FULLSYNC NID_TYPE_FULLSYNC NAME_TYPE_FULLSYNC NAME_PREFIX_SUFFIX_FULLSYNC1 NAME_PREFIX_SUFFIX_FULLSYNC2 NAME_PREFIX_SUFFIX_FULLSYNC3 NAME_PREFIX_SUFFIX_FULLSYNC4 TITLE_FULLSYNC ADDRESS_TYPE_FULLSYNC POI_TYPE_TBL_FULLSYNC ETHNIC_GRP_FULLSYNC US_SOC_FULLSYNC SUPPORT_DOC_FULLSYNC VISA_PERMIT_FULLSYNC COMPETENCY_FULLSYNC3
Page 10 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
For more information, see the Implementing Integration of Setup Data between CS and HCM guide available on My Oracle Support. This document references the configuration and execution steps for using the delivered services to keep setup data in sync.
Incremental S ynchronization
Data in the supporting tables in your system of record may change over time after the initial loading of setup, transactional data, and security data. Use incremental sync (Sync) services to send this information from your system of record to your subscribing target system to maintain data integrity. An incremental sync captures data that was created, added, changed, or deleted in the system of record since the last synchronization. It uses the captured data to overwrite the same data in the subscribing system, thereby refreshing the subscribing system so that both systems have the same data. After the initial Fullsync data loads have completed in your subscribing target system, you may inactivate the associated FullSync services, and then activate the appropriate incremental Sync services to keep your systems updated.
Page 11 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
HCM Table PERSON PERS_DATA_EFFDT PERS_DATA_USF* PERS_NID NAMES ADDRESSES EMAIL_ADDRESSES PERSONAL_PHONE PERS_SMOKER* PERSON_BRA* PERS_DATA_BRA* PERS_DATA_CAN PERS_DATA_CHE* PLACE_ORIG_CHE* PERS_HUKOU_CHN* PERS_DATA_DEU* NATIONALITY_GER* PERS_DATA_ESP* PERSON_FRA* PERS_DATA_FRA* PERS_DATA_IND* PERS_DATA_ITA* PERS_DATA_JPN* PERS_DATA_MEX* PERS_DATA_USA PERS_DATA_FPS* PERSON_SA
*Existing CS functionality does not populate these tables. Depending on your use of HCM functionality, the records marked with an asterisk may not have data present at the time the Fullsync is published. PERS_POI_FULLSYNC.VERSION_1 PER_POI_TYPE PER_POI_SCRTY PER_POI_SCR_DT PER_POI_TRANS DISABILITY ACCOM_REQUEST DISABILITY_FRA* DISABILITY_GER* DISABILITY_CHE* DISABILITY_ESP* DISABILITY_BRA* DISABILITY_NLD* DISABILITY_NZL*
PERSON_DISABILITY_FULLSYNC.VERSION_2
Page 12 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Integration Name
HCM Table *Existing CS functionality does not populate these tables. Depending on your use of HCM functionality, the records marked with an asterisk may not have data present at the time the Fullsync is published.
PERSON_DIVERSITY_FULLSYNC.VERSION_2
DIVERSITY DIVERS_ETHNIC DIVERS_RELIGION* *Existing CS functionality does not populate these tables. Depending on your use of HCM functionality, the records marked with an asterisk may not have data present at the time the Fullsync is published.
PERSON_VISA_CITIZEN_FULLSYNC1.VERSION_1 PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1
Workforce Data HCM to Campus Solutions 9.0 Your HCM system is the system of record for managing all employee job, benefits, and payroll records. Therefore, all Job related transactional data should be maintained in your HCM system. There are times, however, when Campus Solutions must be able to access and use certain workforce related data, such as identifying when an individual is a current employee. Use the WORKFORCE_FULLSYNC service operation to initially populate, or refresh, your CS instance with this information. WORKFORCE_FULLSYNC.VERSION_3 PER_ORG_ASGN PER_ORG_INST JOB JOB_JR COMPENSATION JOB_EARNS_DIST JOB_AUS JOB_IND JOB_MIL JOB_USF HR_EE_SNR_DATES BEN_PROG_PARTIC PER_ORG_ASG_BEL PERS_REGIST_BEL PER_ORG_ASG_MIL PER_ORG_ASG_BRA PER_ORG_ASG_HP HP_EMPLT_TEACH PER_ORG_ASG_JPN PER_ORG_ASG_FA PER_ORG_ASG_NLD
Page 13 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
PERSON_BASIC_SYNC.VERSION_4 PERSON_DISABILITY_FULLSYNC.VERSI ON_2 PERSON_DISABILITY_SYNC.VERISON_2 PERSON_DIVERSITY_FULLSYNC.VERSIO N_2 PERSON_DIVERSITY_SYNC.VERSION_2 PERSON_VISA_CITIZEN_FULLSYNC1.VE RSION_1 PERSON_VISA_CITIZEN_FULLSYNC2.VE RSION_1 PERSON_VISA_CITIZEN_SYNC.VERSION_ 1 WORKFORCE_FULLSYNC.VERSION_3 WORKFORCE_SYNC.VERSION_3
PERSON_DATA PERSON_DATA
PERSON_DATA PERSON_DATA
PERSON_DATA PERSON_DATA
PERSON_DATA
Included in the deliverables to support CS HCM integrations are new versions for the PERSON_BASIC_SYNC/FULLSYNC, PERSON_DIVERSITY_SYNC/FULLSYNC and WORKFORCE_SYNC/FULLSYNC service operations and messages. These new versions include data that was not included in previous versions and was created specifically for integration between two HCM databases (e.g. 9.1 Talent Management integrations), and for integration between CS and HCM. At the moment, these new versions are not being used for integration between HCM and CRM, HCM and FSM, etc. Over time other products will develop subscriptions using the new message versions. An INTERNAL version has also been added as the new default for all three messages. Not that it is only for the local publication. No external databases should be subscribing to this version. The existing versions of the messages were not changed.
Page 14 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM The service operation routings for the integrations with other pillars should be created with the INTERNAL version and can be modeled on the delivered demo routings, e.g. PERSON_BASIC_SYNC_HR_TO_CR_V2, PERSON_DIVERSITY_SYNC_HR_EP_V1, WORKFORCE_FULL_HR_TO_LM_V1. The routing parameters are for the different message/versions are:
Message.ver into Transform 1 PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_SYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_BASIC_FULLSYNC.INTERNAL PERSON_DIVERSITY_SYNC.INTERNAL PERSON_DIVERSITY_SYNC.INTERNAL PERSON_DIVERSITY_FULLSYNC.INTERNA L PERSON_DIVERSITY_FULLSYNC.INTERNA L WORKFORCE_SYNC.INTERNAL WORKFORCE_SYNC.INTERNAL WORKFORCE_SYNC.INTERNAL WORKFORCE_SYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL WORKFORCE_FULLSYNC.INTERNAL
Transform Program 1 PDATA_SYNCV1 PDATA_SYNCV2 HMTF_TR_OA HMTF_TR_OA PDATA_FULLV1 PDATA_FULLV2 HMTF_TR_OA HMTF_TR_OA HCM_MSG_XFR M HMTF_TR_OA HCM_MSG_XFR M HMTF_TR_OA WORK_SYNCV1 HMTF_TR_OA HMTF_TR_OA HMTF_TR_OA WORK_FULL_V1 HMTF_TR_OA HMTF_TR_OA HMTF_TR_OA
Message.ver out of Transforms PERSON_BASIC_SYNC.VERSION_1 PERSON_BASIC_SYNC.VERSION_2 PERSON_BASIC_SYNC.VERSION_3 PERSON_BASIC_SYNC.VERSION_4 PERSON_BASIC_FULLSYNC.VERSION_1 PERSON_BASIC_FULLSYNC.VERSION_2 PERSON_BASIC_FULLSYNC.VERSION_3 PERSON_BASIC_FULLSYNC.VERSION_4 PERSON_DIVERSITY_SYNC.VERSION_1 PERSON_DIVERSITY_SYNC.VERSION_2 PERSON_DIVERSITY_FULLSYNC.VERSION_ 1 PERSON_DIVERSITY_FULLSYNC.VERSION_ 2 WORKFORCE_SYNC.VERSION_1 WORKFORCE_SYNC.VERSION_2 WORKFORCE_SYNC.VERSION_3 WORKFORCE_SYNC.VERSION_4 WORKFORCE_FULLSYNC.VERSION_1 WORKFORCE_FULLSYNC.VERSION_2 WORKFORCE_FULLSYNC.VERSION_3 WORKFORCE_FULLSYNC.VERSION_4
The new messages have been delivered in the following resolutions and bundles:
Release 9.1
PERSON_BASIC_SYNC/FULLSYNC and PERSON_DIVERSITY_SYNC/FULLSYNC WORKFORCE_SYNC
Release 9.0
PERSON_BASIC_SYNC/FULLSYNC and PERSON_DIVERSITY_SYNC/FULLSYNC WORKFORCE_SYNC
Page 15 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Note: The examples shown for the source and target database configuration tasks are of CS 9.0 (source) and HCM 9.1 (target) on PeopleTools 8.51.03 Source Database CS 9.0 Configuration Tasks
1. Update security by adding the Service Operation(s) to your primary permission list:
a. b. c. d. e. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box. Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to use.. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page by selecting the Full Access option for the Access column.
Page 16 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 17 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 18 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 19 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 20 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 7 PERSON_DATA Queue Status Target Database HCM 9.1 Configuration Tasks
1. Update security by adding the service operation to the required users permission list.
a. b. c. d. e. f. g. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box (primary permission list for the user). Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to leverage. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page. Click OK to return to the Web Services page. Click Save to save the updated Permission List.
Page 21 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
2. Activate Service Operation(s) and Create Routing(s) and Subscription Handler in HCM 9.1:
Go to PeopleTools > Integration Broker > Integration Setup > Service Operations. Select PERSON_BASIC_SYNC from the search dialog box. Check the Active check box on the General tab. Make note of the Queue Name field, as you will verify that the PERSON_DATA Queue is in Running status later. e. Click on the Handlers tab. Set the SCC_HR_PERSON handler to Active f. Click on the Routings tab and add a new routing for the Service Operation by entering a value in the Routing Name field and clicking the Add button. g. Enter the CS 9.0 Sender Node and an HCM 9.1 Receiver Node on the Routings Definition page of the Routings component. h. Verify that the Active check box is checked. i. Click the Parameters tab. j. Enter External Alias = PERSON_BASIC_SYNC.VERSION_4 k. Enter Message.Ver into Transform 1 = PERSON_BASIC_SYNC.VERSION_4 l. Enter Transform Program = HMTF_TR_IA m. Enter Message.Ver out of Transforms = PERSON_BASIC_SYNC.INTERNAL n. Click the Save button at the bottom of the Parameters page to save the routing. o. Click the Return button at the bottom of the Parameters page to return to the Service Operation setup page. p. Save the Service Operation by clicking the Save button at the bottom of any of the pages in the Service Operations component. a. b. c. d.
Page 22 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 23 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 24 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 25 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 26 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 27 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
The Person Batch Publish Process is used with several delivered CS SQR and Cobol processes. You will need to activate the appropriate Batch Publish rule to properly publish the person messages when these processes run.
Page 28 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Activate PERSON_BASIC_SYNC Publish Rule To activate the PERSON_BASIC_SYNC Batch Publish rule, navigate to Enterprise Components> Integration Definitions> Batch Publish Rules Select the PERSON_BASIC_SYNC Message Name Set Status = Active
Figure 16 PERSON_BASIC_SYNC Batch Publish Rule Activate PERSON_DIVERSITY_SYNC Publish Rule To activate the PERSON_DIVERSITY_SYNC Batch Publish rule, navigate to Enterprise Components> Integration Definitions> Batch Publish Rules Select the PERSON_DIVERSITY_SYNC Message Name Set Status = Active
Page 29 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 17 PERSON_DIVERSITY_SYNC Batch Publish Rule Handling Custom Programs If you plan to implement your CS HCM integrations following the Owner/Subscriber or Subscriber Only approach, you should thoroughly review your custom processes. Any of these custom processes which can add or update person bio-demo records should be evaluated and you should determine if you need them to publish the appropriate person messages. Depending on how your customizations are implemented, you may choose between any number of options to properly implement the methods to publish the necessary messages. Option 1: The most expedient action you can take is to incorporate the delivered SQC or COBOL modules in your current SQRs and COBOL programs. These modules contain the logic to stage the personal data being added or updated, and then batch publish message for creating a Person record (that is, publish the Person_Basic_Sync message). Option 2: If the custom batch jobs you are evaluating are designed to load Applicants, you may incorporate use of the Constituent and Application Transactions staging records and the Transaction Management process. These capabilities were delivered initially in July 2010 for the CS 9.0 codeline. (To find out more about this option, please see CS 9.0 Bundle #20 Functional Documentation and Additional Features January 2011 [ID 1282397.1] in My Oracle Support; Oracle's PeopleSoft Enterprise Campus Solutions 9.0 Admission Applications Web Services Developers Guide Appendix: Loading Applications in Bulk Depending on your external file layout, you may want to use the delivered File Parser utility to move constituent and application data into the appropriate staging tables. Option 3: If the custom batch jobs you are evaluating are designed to load Prospects, you may use the delivered Test Score Load processes, if appropriate. If your batch jobs for loading Prospects are not from a source included in delivered CS functionality (i.e. External Test Score , you may want to incorporate the batch publish design pattern in your custom batch jobs. Option 4: If your custom job uses an Application Engine process which was modeled after the CS Recruiting and Admissions Test Score Posting program (SAD_TEST_POST), then you have included the code needed to publish PERSON_BASIC_SYNC. Therefore, your custom Application Engine processes should not require modification.
Page 30 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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)
Note. Standard HR department row-level security is not enforced on delivered CS components used to maintain person data. HR users will have access to all employee records through CS components. You will need to carefully plan which components you wish to deploy to your administrative users to manage personal information.
For more information, see the Implementing Portal Navigation Aggregation between CS and HCM guide.
The diagrams below demonstrate some high-level examples of these business processes, and how the data is messaged between your CS and HCM database.
Page 31 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 32 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 33 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 34 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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.
Page 35 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
10. Update the HR Gateway nodes in the CS database. 11. Update the Single Sigonon nodes. 12. Testing Nodes
Page 36 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM b. c. d. e. f. g. h. i. j. k. l. Select the default local node. Set Descr = 'HCM 9.1 Instance'. Set Authentication Option = 'Password'. Node Password = 'PS'. Default User ID = 'PS'. Click the 'Connectors' tab. Use gateway ' LOCAL'. Set Connector Id = 'PSFTTARGET'. Click the Portal tab. Set Tools Release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string. Set Application Release = 'HCM 9.1'.
m. Set Content URI Text = ' http://machinename:port/psc/SPLTHL91'. n. o. p. q. r. Set Portal URI Text = ' http://machinename:port/psp/SPLTHL91'. Click the WS Security tab. Set Authentication Token Type = 'none'. Disable the 'encrypted' checkbox. Click Save
a. b. c. d. e. f.
Navigation: PeopleTools > Integration Broker > Integration Setup > Nodes. Add Node = <Name of CS 9.0 Node> Set Descr = CS 9.0 Instance'. Set Authentication Option = 'Password'. Node Password = 'PS' Default User ID = 'PS'
Page 37 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM g. h. i. j. k. l. Click the 'Connectors' tab Set Gateway = ' LOCAL' Set Connector ID = 'PSFTTARGET' Click the Portal tab Set Tools Release = '8.50.xx (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string) Set Application Release = 'CS 9.0'.
m. Set Content URI Text = 'http://machinename:port/psc/databasename' n. o. p. q. r. Set Portal URI Text = 'http://machinename:port/psp/databasename'. Click the WS Security tab. Set Authentication Token Type = 'none'. Disable the 'Encrypted' checkbox. Click Save.
m. Set Content URI Text = ' http://machinename:port/psc/databasename n. o. p. q. r. Set Portal URI Text = ' http://machinename:port /psp/databasename Click the WS Security tab. Set Authentication Token Type = 'none'. Disable the 'encrypted' checkbox. Click Save.
Page 38 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
m. Set Content URI Text = ' http://machinename:port/psc/databasename n. o. p. q. r. s. Set Portal URI Text = ' http://machinename:port/psp/databasename Click the WS Security tab. Set Authentication Token Type = 'none'. Disable (turn off) the Encrypted checkbox. Click Save. Node Saved message box. Click OK.
a. b. c. d. e. f. g.
Navigate: PeopleTools > Integration Broker > Configuration > Gateways. Select gateway 'LOCAL'. Select the 'Gateway Setup Properties' link. User ID = administrator Password = password Click OK. In the 'Gateway Default App. Server' frame, Set the App Server URL = ' //machinename:port (Note: your port must match that specified in your HCM application server.) Page 39 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM h. i. j. k. l. Enter the appropriate User ID Enter the appropriate Password Set the tools release = '8.50.xx'. (Note: by pressing the <CTL>+J keys, you should be able to see the tools release string.) Make sure both the HCM and CS nodes are in the 'PeopleSoft Nodes' tab
10. Update the Single Signon nodes in both CS and HCM databases
Single signon is used in this recommended configuration. a. b. Navigate: PeopleTools > Security > Security Objects > Single Signon. Make sure that both the default local node and the other node you will be using are listed.
11.
Testing Nodes
Both nodes must be 'pingable' from each database. a. b. c. Navigate: PeopleTools > Integration Broker > Service Operations Monitor > Administration> Node Status. Do this on each database. For each node name, enter its name and click the 'Ping Node' button. It should respond with 'Success'.
Page 40 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
12. Update security by adding the Service Operation(s) to your primary permission list:
a. b. c. d. e. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box. Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to use.. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page by selecting the Full Access option for the Access column.
Page 41 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 42 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 43 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 28 Service Operations Routings v. w. x. y. z. Enter a Sender Node and a Receiver Node on the Routings Definition page of the Routings component. Verify that the Active check box is checked. Click the Save button at the bottom of the Routings Definition page to save the routing. Click the Return button at the bottom of the Routings Definition page to return to the Service Operation setup component. Save the Service Operation by clicking the Save button at the bottom of any of the pages in the Service Operations component.
Page 44 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 45 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
15. Update security by adding the service operation to the required users permission list.
a. b. c. d. e. f. g. Go to PeopleTools > Permissions & Roles > Permission Lists. Select the relevant permission list from the search dialog box (primary permission list for the user). Go to the Web Services tab. Enter the corresponding Service(s) for the Service Operation(s) you wish to leverage. Click on the Edit link and add access to the relevant Service Operation(s) listed on the Web Service Permissions secondary page. Click OK to return to the Web Services page. Click Save to save the updated Permission List.
Page 46 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 47 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM a. b. c. d. Go to PeopleTools > Integration Broker > Integration Setup > Service Operations. Select the relevant Service Operation(s) from the search dialog box. Check the Active check box on the General tab. Make note of the Queue Name field, as you will need to verify that the Queue is in the Running status later.
Figure 33 Service Operation Definition e. f. g. h. i. j. Click on the Routings tab and add a new routing for the Service Operation. Enter a Sender Node and a Receiver Node on the Routings Definition page of the Routings component. Verify that the Active check box is checked. Click the Save button at the bottom of the Routings Definition page to save the routing. Click the Return button at the bottom of the Routings Definition page to return to the Service Operation setup component. Save the Service Operation by clicking the Save button at the bottom of any of the pages in the Service Operations component.
Page 48 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM d. e. f. g. h. i. j. k. l. Set Type = OnNotify Set Implementation = Application Class Set Status = Active Click on Details link Set Package Name = [see Table 2 FullSync Service Operations listed above (Application Package Name/ Class/ Method column) for the required value for this field. (Example: GEN_UPG_HANDLER_12332 )] Set Path = : Set Class ID = [see Table 2 FullSync Service Operations listed above (Application Package Name/ Class/ Method column) for the required value for this field. (Example: CountryFullSync) Set Method = OnNotify Click OK to return to the Handlers setup page.
m. Click Save button at the bottom of the Handlers page to save your changes.
Page 50 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 51 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 52 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 40 Process Scheduler Request 1. Go to PeopleTools > Integration Broker > Service Operations Monitor > Monitoring > Aynchronous Services to review the status of the Full Sync messages created by the Full Data Publish process.
Page 53 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 54 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 55 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 56 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 57 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 58 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 59 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 60 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 42 PERSON_BASIC_FULLSYNC.VERSION_4
Page 61 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 62 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 63 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 64 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 65 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 66 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 43 PERSON_BASIC_SYNC.VERSION_4
Figure 44 PERS_POI_FULLSYNC
Copyright Oracle USA 2010. All rights reserved.
Page 67 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 45 PERS_POI_SYNC
Page 68 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 69 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 70 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 46 PERSON_DISABILITY_FULLSYNC.VERSION_2
Page 71 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 72 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 73 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 74 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 47 PERSON_DISABILITY_SYNC.VERSION_2
Page 75 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 48 PERSON_DIVERSITY_FULLSYNC.VERSION_2
Page 76 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 49 PERSON_DIVERSITY_SYNC
Page 77 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 50 PERSON_VISA_CITIZEN_FULLSYNC.VERSION_1
Page 78 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 51 PERSON_VISA_CITIZEN_FULLSYNC2.VERSION_1
Page 79 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 80 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 52 PERSON_VISA_CITIZEN_SYNC.VERSION_2
Page 81 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 82 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 83 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 84 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 85 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 86 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 87 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 88 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 89 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 90 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 91 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 92 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 93 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 94 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 53 WORKFORCE_FULLSYNC.VERSION_3
Page 95 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 96 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 97 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 98 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Page 99 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Figure 54 WORKFORCE_SYNC.VERSION_3
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM program will update the status in the parameter table to Complete, and either update the process instance, audit action, and process flag in the application tables or delete the rows from the staging tables. If Message Chunking has been set up for the message a separate message is published for each new value of the chunking field(s). The Batch Publish program will optionally produce a header and trailer message for all subscribers to the message. The messages will be delivered to the subscribing system in the order in which they are published. Note. Batch Publish is an incremental publish, and as such, only publishes in the user's base language. For example, if the base language is English and the message data is chunked by Business Unit, the messages created by the Batch publish program could be: 1. Header message (optional) 2. English Business Unit A message 3. English Business Unit B message 4. .... 5. English Business Unit Z message 6. Trailer message (optional) For more information about message chunking and routing, header and trailer information and the Publish Definition page, see Setting Up Message Publishing.
Topics
When You Should Use This Design Pattern When You Shouldn't Use This Design Pattern Process Flow Automated Version Process Flow Manual Version
Examples To publish Incremental Changes from large transactions such as the Payroll Acknowledgement of Expense Payment Request or Inventory Shipping Transaction.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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).
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Process Steps 1. Application batch program is run as standalone process. Process can run on Client or Server.
Copyright Oracle USA 2010. All rights reserved.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM 2. The application program will either insert modified rows to a staging table, or flag modified rows in PeopleSoft Application Tables. 3. A single row is inserted in a Batch Parameter table that contains the parameters needed by the AE publishing program as a trigger to publish that batch programs data. 4. Batch Publish may be scheduled from an online page. 5. Online parameter file contains the application batch program (step 1). 6. The Batch Publish program selects all of the changed data based on the parameters in the Online and Batch Parameter tables and publishes the message(s).
Developer Activities
To design a Batch Publish EIP:
1. Determine Batch Publish process method 2. Identify Source tables for batch publish 3. Create or modify source tables 4. Create the Message Definition 5. Create the Publish Definition 6. Create Chunking Rules 7. Modify the application batch program 8. Create Automated Publish Job Definition, if using the automated process 9. Create Manual Publish Run Control, if using the manual process 10. Test
Topics
Activity 1 Determine Batch Publish Process Method Activity 2 Identify Source Tables for Batch Publish Activity 3 Create or Modify Source Tables Activity 4 Create the Message Definition Activity 5 Create the Publish Definition Activity 6 Create Chunking Rules Activity 7 Modify the Application Batch Program Activity 8 Create Automated Publish Job Definition Activity 9 Create Manual Publish Run Control Activity 10 Test
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM o o o o o o o Automated Batch Publish Process (AE) Publish is done as last step in application AE program No restrictions on where processes can run Manual Batch Publish Process Need to schedule the batch publish process No restrictions on where processes can run May be a substantial delay between the time the data is flagged for publish and when the actual publish takes place. This could cause problems if application tables are being flagged and the user is not locked from making changes. Could also cause problems for the user if they have to wait for the publish program to run before making online changes.
We show two use cases below, one calling Batch Publish from an AE program and the other use case showing Batch Publish being run after an SQR program. Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) When Expenses sends Payroll a Request for Payment, Payroll must send back a message acknowledging the request. As this new business process added functionality, Payroll decided to write a new AE program, PY_EXPVALIDT. The new AE program would read the Expense Request message, validate the data and store a copy of the original message data with the status of accepted or rejected in staging tables, then publish a message back using the staging tables to the Expenses system. The Batch program could delete the staging tables immediately after the message was published. The new AE program could also leverage the fact that the Batch Publish program was also written in AE and could call the Batch Publish program directly as the last step within the new AE program. Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) When Payroll creates Paychecks, it must notify Expenses of this fact by sending out a Payment Issued message. An existing program, PAYGL01.SQR contains the logic to create the data needed for the Payment Issued message, so it was decided to modify this program to write payment data to a staging table and publish the staging table by calling Batch Publish with a separate manual job. The Batch Publish program would then delete the staging tables immediately after the message was published.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Requires addition of the following fields to each table: Process Instance Audit Action In Process Flag Does not handle deletes. Allows the ability for Application Batch programs and online pages to restrict updates until message is sent. Requires application program to flag records to be published at each level.
Using staging tables Requires creation of new tables (possibly). Staging tables must contain same field names as tables in message definition. Staging tables require the following additional fields: Process Instance Audit Action In Process Flag Will handle deletes. Does not allow Application Batch programs and online pages to restrict updates until message is sent.
Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) For the Payroll Acknowledgement message, in order to avoid any conceivable complications by publishing from the application tables, a staging table was created that would contain a copy of the application data. This way, the original application tables that were needed for the next step in the Payroll process would not need to be modified if the contents of the Acknowledgement message had to be changed. The original application record name was PAY_ACKNOWLEDGE. The staging table created was called PAY_ACK_STG_PUB. Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) Since this was an existing SQR program and since Payroll did not want to worry about the messaging data requirements affecting the processing on the payment issuing application tables, staging tables would be created that would contain a copy of the application tables needed for the Payment Issued message. The original application record name was PAY_ISSUED. The staging table created was called PAY_ISS_STG_PUB.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM C - Row changed but no key fields changed. The old values are written to the audit table. K - At least one key field changed. The old values are written to the audit table. N - At least one key field changed. The new values are written to the audit table. It must contain the field PROCESS_INSTANCE to identify data that was changed by a particular batch run. The process instance field on the source tables is necessary to support processing in parallel. It provides applicationcontrolled row locking. In set processing, the Application Batch program selects rows from the application tables where PROCESS_INSTANCE=0. It updates process instance in the application tables to lock the rows. When processing is complete and application tables have been updated, it usually zeroes out process instance to release the data for other processes. This last step now becomes the responsibility of the AE generic Batch Publish program. It must contain the field IN_PROCESS_FLAG. This field is currently being used by Purchase Order Management to lock the row from being updated online. Fields that are in the source table and in the message definition must have the same name. The source tables do not need to be the same as the tables that comprise the message definition. This means you can publish data from tables A, B, and C using a message definition that references tables X, Y, and Z. For example, suppose you want to delete records from an application table. When you publish a message based on this table, the deleted records are no longer in the table, and therefore not published. Instead, you can load the deleted rows into a staging table, then publish the message, specifying that the data in the staging table be used instead of the data in the application table.
Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) The PAY_ACK_STG_PUB staging record was created to store the Expense Payment Request Acknowledgment information and set an acceptance status depending if the line item passed payroll validations or not. This table would be used to publish the message and would be deleted after the message was published. Besides the fields needed for the message only the AUDIT_ACTN and PROCESS_INSTANCE fields were added. No chunking is needed on this message at this time.
PAY_ACK_STG_PUB Staging Record Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) The PAY_ISS_STG_PUB staging record was created to store the data needed for the Payment Issued message that needs to be published. Again since this is a staging record, besides the data in the original Paysheet fields, only additional fields for AUDIT_ACTN and PROCESS_INSTANCE needed by the Batch Publish program were added.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) Message PAYMENT_EXPENSES_ACKNOWLEDGE was created to consist of a single record, PAY_ACKNOWLEDGE and it contains the same application fields as its staging table, PAY_ACK_STG_PUB.
PAYMENT_EXPENSES_ACKNOWLEDGE Message Definition Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) Message PAYMENT_EXPENSES_ISSUE was created to consist of a single record, PAY_ISSUED and contains the same application fields as the staging record, PAY_ISS_STG_PUB.
Publish Rule Definition Panel for PAYMENT_EXPENSES_ACKNOWLEDGE PAY_ACK_STG_PUB is entered as the publish staging table for the PAY_ACKNOWLEDGE message record within the Publish Rule.
Publish Rule Record Mapping Panel for PAYMENT_EXPENSES_ACKNOWLEDGE The application program name, PY_EXPVALIDT is entered as the Batch Program name for the Publish Rule.
Publish Rule Batch Programs Panel for PAYMENT_EXPENSES_ACKNOWLEDGE Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) A new Publish Rule, PAY_ISSUED, is added that will publish the entire contents of the PAYMENT_EXPENSES_ISSUE message without chunking it.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM 4. This will return field JOBINSTANCE in EO_BATLIB_AET For SQR Programs: 1. Include stdapi.sqc in your program 2. Call Get-Run-Control-Parms 3. This will return #prcs_job_instance and #prcs_process_instance Adding logic to check for active publish definitions This is an optional step. The following routines will return a count of the active messages to be published by this program. If there are no active messages to publish then appropriate logic can be invoked. For example the application program could abort processing or logic could be added that would clear the IN_PROCESS_FLG when the program completes. For AE programs: 1. Add state record EO_BATLIB_AET to your AE program 2. Set PROCESS_NAME in EO_BATLIB_AET to the PROCESS_NAME of your AE program 3. Call section ACTIVE in EOL_PUBLISH 4. Field ACTIVE in EO_BATLIB_AET will contain the count of active Publish Rules to be published For SQR Programs: 1. Include EOPRCSNM.SQC, EOPARAM and EOACTIVE.SQC 2. Call Get-Active-In-BatchPub 3. Returns #cntmsg (count of active Publish Rules to be published) Modifying the SQL to select only records with PROCESS_INSTANCE = 0 You'll need to find the place in the SQL code that selects the source data for update to make this modification. The process instance field is used to lock rows of data from processing until the Batch Publish has published the message for those rows. The Batch Publish program will then update value the process instance field to zero. Only rows with a zero value in the process instance field are available for further updates. Example of a modified Select
SELECT FIELD_1, FIELD_2 FROM PS_APPL_TBL WHERE BUSINESS_UNIT=$BU AND ITEM_ID='1234' AND PROCESS_INSTANCE=0; Example of a modified Update: UPDATE PS_APPL_TBL SET FIELD_1='A', FIELD_2=[$AsOfToday], PROCESS_INSTANCE=#PROCESS_INSTANCE, PROCESS_INSTANCE=#PROCESS_INSTANCE, AUDIT_ACTN='C' WHERE BUSINESS_UNIT=$BU AND ITEM_ID='1234' AND
PROCESS_INSTANCE=0;
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Modifying the SQL to update the Audit Action, Process Instance and In Process flags You'll need to find the place in the SQL code that updates or inserts data into the Source Tables to make this modification. The batch program has to populate the AUDIT_ACTN, PROCESS_INSTANCE and IN_PROCESS_FLG fields at the time it updates or inserts data. If the batch program adds a row, it must set AUDIT_ACTN=A on that row in the source table. If the batch program changes a row, it must set AUDIT_ACTN=C in the source table. If the batch program deletes a row, it must set AUDIT_ACTN=D in the source table (Must use staging tables for deletes). The PROCESS_INSTANCE is set to the actual process instance of the Batch Program. Example of a modified Insert
INSERT INTO PS_APPL_TBL (FIELD_1, FIELD_2, PROCESS_INSTANCE, AUDIT_ACTN) AUDIT_ACTN VALUES ('A', $AsOfToday, #PROCESS_INSTANCE, 'A' Example of a modified Update: UPDATE PS_APPL_TBL SET FIELD_1='A', FIELD_2=[$AsOfToday], PROCESS_INSTANCE=#PROCESS_INSTANCE, AUDIT_ACTN='C' WHERE BUSINESS_UNIT=$BU AND ITEM_ID='1234' AND
PROCESS_INSTANCE=0;
AE Set Processing Example An Update statement with a Where clause that affects multiple rows is fairly straightforward. What's more common is achieving an update by selecting rows from one temp table, inserting them into another temp table, and changing values along the way. The following sample addresses that scenario. Note that although the statement is an Insert, the audit action is 'C'.
INSERT INTO PS_TMPA_TBL (PROCESS_INSTANCE GROUP_BU, PROCESS_INSTANCE, PROCESS_INSTANCE GROUP_ID, OPRID, ASSN_OPRID, BUSINESS_UNIT, GROUP_TYPE, BAL_STATUS, EDIT_STATUS, POST_STATUS,... AUDIT_ACTN AUDIT_ACTN) SELECT &BIND(PROCESS_INSTANCE), G.GROUP_BU, G.GROUP_ID, G.OPRID, G.ASSN_OPRID, G.BUSINESS_UNIT, G.GROUP_TYPE, T.BAL_STATUS, 'E', 'E',... 'C') 'C' FROM PS_TMPT_TBL, PS_GROUP_CONTROL G, PS_TMPP_TBL P WHERE T.PROCESS_INSTANCE = &BIND(PROCESS_INSTANCE) AND G.GROUP_BU = T.GROUP_BU AND G.GROUP_ID = T.GROUP_ID AND P.PROCESS_INSTANCE = &BIND(PROCESS_INSTANCE) AND P.GROUP_BU = G.GROUP_BU AND P.GROUP_ID = G.GROUP_ID
GROUP BY G.GROUP_BU, G.GROUP_ID, G.OPRID, G.ASSN_OPRID, G.BUSINESS_UNIT, G.GROUP_TYPE, T.BAL_STATUS, G.CONTROL_AMT, G.CONTROL_CNT...
Modifying application programs to pass parameters via the Parameter Table The application program passes parameters to the Batch Publish program by inserting a single row into a Batch Parameter table. The Batch Publish program uses the parameters, process instance, and program name to pull control data from setup tables that define what is published from each program. The following routines will update the Batch Parameter table.
Copyright Oracle USA 2010. All rights reserved.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM For AE programs: 1. Add State Record EO_BATLIB_AET to your AE program 2. Set Fields JOBINSTANCE, PROCESS_INSTANCE and PROCESS_NAME in EO_BATLIB_AET. This will not be necessary if Sections GETJOB and ACTIVE were called earlier in your AE program 3. Set field BATCH_CLEANUP_FLG. Valid values and actions are: o o o o 4. Blank - No cleanup of source table data is done D - Published rows are deleted from the source table U - IN_PROCESS_FLG of published rows is set to "X" C - IN_PROCESS_FLG and AUDIT_ACTN of published rows is set to blanks and PROCESS_INSTANCE is set to zero
For SQR Programs: 1. Include EOPARAM.SQC in your program 2. Set $batch_cleanup_flg. Valid values and actions are: o o o o 3. Blank - No cleanup of source table data is done D - Published rows are deleted from the source table U - IN_PROCESS_FLG of published rows is set to "X" C - IN_PROCESS_FLG and AUDIT_ACTN of published rows is set to blanks and PROCESS_INSTANCE is set to zero
Call Insert-Param-In-BatchPub
The following table describes the parameters for this procedure: Parameter PROCESS_INSTANCE Key Yes Description PROCESS_INSTANCE of the COBOL, SQR, or Batch program which flagged the records for publishing. The AE Publish program will use this value to find the records modified by the application program. JOBINSTANCE of the COBOL, SQR, or Batch program which flagged the records for publishing. This field will contain a zero if the batch program ran as a standalone process. In the automated publish process the AE Publish Program will use the JOBINSTANCE to find the PROCESS_NAME it needs to publish. The name of the COBOL, SQR, or AE program. This field is the key to the control data used to structure the message. Application batch programs will populate this field with an 'N' (Pending). The Batch Publish program will change it to 'P' (Processing) while the publish is in process and to a 'C' (Complete) when the publish is done. This field must be set by the application program prior to calling the generic function for inserting the row. The valid values and their actions are: Blank - no cleanup processing is done. D - the published rows are deleted from the source table.
JOBINSTANCE
Yes
PROCESS_NAME
PROCESS_STATUS
BATCH_CLEANUP_FLG
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
U - the IN_PROCESS_FLG is set to "X" for published rows. C - the IN_PROCESS_FLG and AUDIT_ACTN are set to blank and PROCESS_INSTANCE is set to zero for all published rows. DATETIMESTAMP The application program will populate this field. Used for information only.
Calling Batch Publish Directly from a Application AE program If the application batch program is an AE program, the Batch Publish AE program may be called as the last step of the application AE program. This will eliminate the need to create a Job Definition. The following logic will call the Batch Publish program directly. For AE programs: 1. Add State Record EO_BATLIB_AET to your AE program 2. Set Fields JOBINSTANCE, PROCESS_INSTANCE and PROCESS_NAME in EO_BATLIB_AET. This will not be necessary if Sections GETJOB and ACTIVE were called earlier in your AE program 3. Set field MSGNODENAME. If a value is entered in this field the Publish utility will copy it to the PSCAMA record in the message object. Routing peoplecode can then be written to return the value to the app server for routing. 4. Call Section PUBLISH in EOL_PUBLISH Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program) Here's the PY_EXPVALIDT program:
PY_EXPVALIDT AE Program Part Two State record EO_BATLIB_AET was added to the application AE program PY_EXPVALIDT.
Adding Records to PY_EXPVALIDT In section INITPROG, a new step, STEP01, performs PeopleCode to update the PROCESS_INSTANCE in the staging table:
UPDATE PS_PAY_RQT_STG_SUB %Bind(PROCESS_INSTANCE) SET PROCESS_INSTANCE =
In section INITPROG, a new step, STEP02, performs PeopleCode to set the PROCESS_INSTANCE in state record EO_BATLIB_AET:
%Select(EO_BATLIB_AET.PROCESS_INSTANCE, EO_BATLIB_AET.PRCSINSTANCE, EO_BATLIB_AET.JOBINSTANCE, EO_BATLIB_AET.PROCESS_NAME) JOBINSTANCE , PRCSNAME %Bind(PROCESS_INSTANCE) SELECT PRCSINSTANCE , PRCSINSTANCE , FROM PSPRCSRQST WHERE PRCSINSTANCE =
In section VALIDATE, a new step, STEP02, inserts data into the Publish staging table and set the AUDIT_ACTN and PROCESS_INSTANCE fields. The AUDIT_ACTN get set to 'A' or 'C' or 'D".
UPDATE PS_PAY_RQT_STG_SUB SET PROCESS_INSTANCE =
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
%Bind(PROCESS_INSTANCE), AUDIT_ACTN = 'A'
Valid employee numbers, earnings codes, currency codes, and amounts were inserted into staging tables, and bad earnings codes, bad employee numbers, bad currency codes, bad amounts and invalid paysheets were inserted into the staging table. Logic to check if PROCESS_INSTANCE = 0 on the select statements before inserting to the publish staging tables wasn't necessary as we are publishing from the staging tables not from application tables. Below shows SQL for bad earnings codes being inserted into PS_PAY_ACK_STG_PUB.
Inserting Bad Earnings SQL Into PS_PAY_ACK_STG_PUB Example of SQL for all valid records which pass all the data being inserted into PS_PAY_ACK_STG_PUB:
Inserting SQL Into PS_PAY_ACK_STG_PUB PeopleCode to check if any records were written to the staging tables was added in section CHECKACK, step01. This would perform a rollback, Exit(1) if no staging table data was found or a commit, Exit(0) if staging table data to be published was found.
SQLExec("SELECT 'X' FROM PS_PAY_ACK_STG_PUB", &PUB_EXIST); If &PUB_EXIST <> "X" Then Exit (0); Else Exit (1);
End-If;
After CHECKACK, the section PUB_SEC in program PY_BATCHPUB was added to perform the check for active Publish Rules for the Program name, to retrieve the Job Instance, to insert the Batch Parameter trigger table for the Batch Publish program, and call the Batch Publish program.
Section PUB_SEC in PY_BATCHPUB AE Program Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) The include files 'stdapi.sqc', 'eoprcsnm.sqc', 'eoactive.sqc', 'eoparam.sqc' were added into the batch program PAYGL01.SQR.
#Include 'stdapi.sqc' #Include 'payrnctl.sqc' #Include 'tranctrl.sqc' #Include 'stderror.sqc' #Include 'sqlerr.sqc' #Include 'eoprcsnm.sqc' #Include 'eoactive.sqc'
#Include 'eoparam.sqc' for Batch Publish
!Update Process API !Get-Run-Control procedure !Transaction control (commits, etc.) !Routine for error display !SQL Error Handling Procedure !Determine Process Name !Determine Active Publish Definition
!Insert values into Parameter Table
Logic was added to the PAYGL01.SQR to get the process instance in procedure 'Get-Run-Control-Parms' by calling 'Stdapi-Init' whose logic is declared in the 'stdapi.sqc' include file.
!*************************** begin-procedure Init-Report !*************************** move 'Payroll GL Interface' to $ReportTitle do Init-DateTime
Copyright Oracle USA 2010. All rights reserved.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
do Init-Number do Stdapi-Init do Initialization move 'N' to $CyclePrompts 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, ime) end-if !-------------------------end-procedure
$SysDateT
-------------------------------------------
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,
Copyright Oracle USA 2010. All rights reserved.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
EX_DOC_TYPE, EX_LINE_NBR, MONETARY_AMOUNT, CURRENCY_CD, PAYCHECK_STATUS, PAYCHECK_NBR, CHECK_DT, FORM_ID, ACCOUNT, AUDIT_ACTN, PROCESS_INSTANCE ) VALUES ($Emplid, #Empl_Rcd, $Ex_Doc_Id, $Ex_Doc_Type, #Ex_Line_Nbr, #Monetary_Amount, $Ex_Currency, $Check_Status, #Check_Iss_Nbr, $Check_Dt, $FormId, $Account, 'A', #Prcs_Process_Instance ); End-SQL
end-procedure
! contains Check #
Job Definition Options for BATCHPUB Job Note. Jobs are not supported on the client; jobs require the scheduling support that only a server environment can offer. Also, only EIP aware processes are allowed in Job Definitions. All processes within a job request notify the server of the run status when they complete. This is how the decision is made to continue with the next job process. Real Use Case 1 - Payroll Acknowledgment of Expense Request (Batch Publish from an AE program)
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM The Batch Publish program EOL_PUBLISH was called as the last step in the new AE PY_EXPVALIDT program so it is unnecessary to set up a job to perform the Batch Publish step. Real Use Case 2 - Notification of Payroll Payment Issued (Batch Publish from an SQR program) A new menu item Payment Notification was created in Compensate Employees, Manage Payroll Process(US) and Manage Payment Process(CAN), Payment Notification to do a manual Batch Publish (EOP_PUBLISM) after all Payroll processes are done.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM Option 2: Run your Application Program followed by running the Batch Publish program as two steps within the same Job Instance.
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).
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM It's your responsibility to identify other programs that may update the flagged application tables and modify them to prevent the flagged data from changing before the Publish program has been run. The generic Batch Publish program should be set up to run immediately after the application program to prevent a time lag before the message is published and to release the row lock as quickly as possible. Circular publishes. Circular publishes are when data added or modified through an inbound message subscription, in turn publishes the data back out to other nodes, including the node that originally sent the first message. This only happens if the business object you are dealing with for the Batch Publish process also has an incremental or full message subscription. If you have this case, you must 1) trap the PubNodeName within the message subscription and 2) set the message attribute DoNotPubToNodeName prior to calling the Publish() function. This will publish the message out to all nodes expecting the message except the one contained in the DoNotPubToNodeName value. Make sure the logic in bold below is added where appropriate. Within the message subscription add the following to trap the originating node name:
PanelGroup string &PUBNODENAME; ... &PUBNODENAME = &MSG.PubNodeName;
...
You will need to save the &PUBNODENAME as a field on one of the inbound staging tables if an application program is later used to validate, insert/modify and publish the new data later down the line. Within the publish logic, if done from on-line Panel Group or record, add the following to make sure the message publishes to all subscribing nodes except the one that originated the business component message:
PanelGroup string &PUBNODENAME; ... &MSG = CreateMessage(Message.UOM_SYNC); If &MSG.IsActive Then &RS0 = GetLevel0(); &MSG.CopyRowsetDelta(&RS0); &PUBNODENAME; &MSG.DoNotPubToNodeName = &PUBNODENAME; &MSG.Publish();
End-If;
If the publish logic is done via the Batch Publish program, as is the case with Batch Publish and EDI Outbound Conversion design patterns, allow the circular message to be published back to the node from where the message originated. However, add a field on the message to save the originating node's name. When this message is published back to the originating node, OnRouteSubscribe logic is added to the channel to screen out messages where the originating node for the message is the node that we are currently on. The message will be sent to all appropriate nodes, however the originating node won't process it.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM processing.. You can write SQL in a way that reduces the number of false positives. Generally, the likelihood of publishing unchanged data occasionally is small. 3. Why do we have to worry about audit action values? The messages we publish from batch need to be indistinguishable from those we publish from online, so we have to insert the same audit action values in our batch messages as Panel Processor does for online messages. 4. What about performance? The Application Messaging architecture is designed to be streamlined and simple, and as an App Server process so it's scalable (by adding Message Brokers and/or App Servers). Preliminary findings show that producing a message is as fast as producing a file, while a message is more seamless to the user. 5. What about concurrent processing? The Parameter table is keyed to allow multiple jobs to be processing different sets of data at the same time. The use of the Process Instance keeps these jobs from stepping on each other. 6. If the AE program uses dedicated temp tables to support parallel processing, will the generic AE subscriber still know which physical tables contain the data? Yes. This is handled under the covers by AE and requires only that the generic publishing program use %TABLE() when referencing record names. 7. Does the Batch Publish design pattern handle 'deletes'? Yes, through the use of staging tables. If you have to publish information about deleting rows of data, you must use staging tables as your source tables. 8. If multiple tables are involved in the batch program that needs to be published, which tables need audit action? All tables needed for the publish message need to contain the appropriate 'add' or 'change' audit action and process instance fields and be inserted to the Parameter table. 9. Is there a way to publish in "set" from a table or set of tables? No. Each row in the Message Object rowset must be populated row by row from the Fetches on the Record Object.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM f. Bad XML syntax.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM 1. Message was edited and has yet to be resubmitted for processing.
M y Publish() PeopleCode finishes successfull y, but there is no message in the Message Monitor
Possible cause: 1. The message definition is inactive. Page 133 of 136
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
5.
Also try to ping both machines using machine names. If that fail, use their IP-addresses instead.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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.
Implementing Person Bio-Demo Data Integration Between Campus Solutions and HCM
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.