Lesson5-HDL-Full Vs Partial History - PPT

HCM
Data Loader (HDL)

Advanced Topics – Employee Data Filtering
Prasanna Borse
Oracle HCM Cloud Center of Excellence
June, 2017
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 2

Agenda
• Full vs Partial Rowset
• Full vs Partial History
• Various use cases for employee data conversion
• HDL Modes (Retain\Replace)
• Bring it all together HDL modes(retain\replace) + Full\Partial Rowsets
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 3
Full vs Partial Rowset (Data set)
• You can send complete or partial rowsets
to report incremental changes. HDL
Existing Data supports both the options.
Effective Start Effective End Action ….. Other • Partial rowsets to report incremental
attributes
changes are more efficient to upload.
01-03-2012 23-11-2012 Hire
There is much less data being moved
24-11-2012 09-07-2013 Assignment Change
around and imported into stage tables.
Incoming Data: Employee was promoted on June 1st 2017
Full Rowset Partial Rowset

Effective Start Effective End Action ….. Other Effective Start Effective End Action ….. Other
attributes attributes
01-03-2012 23-11-2012 Hire 01-06-2016 Promotion
24-11-2012 31-05-2017 Assignment Change
01-06-2017 Promotion

Full vs Partial History
PS\EBS Existing Data
Effective Start Effective End Action ….. Other • Depending on your requirements, you can
attributes convert entire history or partial history
Jan 1990 Mar1995 Hire from source hcm application.
Apr 1995 Dec 1997 Assignment Change
Jan 1998 Nov 1998 Promotion • Example for partial history: Customer
Dec 1998 Feb 2004 Location Change wants to convert last 3 years of employee
…. …. … history into HCM cloud to run
…. …. … compensation & talent.
…. …. …
…. …. …
Jun 2017 Data Change

Employee Data Load
Use Cases
• Complete History - this is pretty straight forward and there isn’t much confusion on data loading
using this approach.
• Partial History: Approach based on……
– Shell\Skeleton of the data
– Cut-off date
– Top of the stack
– Basic Worker
Incremental: Send Incremental: Incremental:
Onetime Conv
All Changed WR Changed Row
Complete history
Partial History: Shell Data **Recommend?**
Partial History: Cut off
date
Partial History: top of
stack
Partial History: No history

Employee Data Load
• Use Case: Complete History
1. One time Conversion (Full rowset)
2. Incremental Updates
1. Send All (Full rowset)
2. Only the changed work relationship(s) (Full rowset)
3. Only the changed transaction(s) (partial rowset)

Converting Complete History
One-time Conversion
Employee Data: Source System Employee Data: HCM Cloud
Work Effective Action Work Effective Action
Relationship Date Relationship Date
WR1 2002 Hire WR1 2002 Hire
WR1 2003 Assignment Change WR1 2003 Assignment Change
WR1 2004 Salary Change WR1 2004 Salary Change
WR1 2005 Termination WR1 2005 Termination
WR2 2006 Rehire WR2 2006 Rehire
WR2 2007 Data Change WR2 2007 Data Change
WR2 2008 Promotion Full Rowset WR2 2008 Promotion
WR3 2012 Location Change WR3 2012 Location Change
WR3 2013 Promotion WR3 2013 Promotion
WR3 2014 Manager Change WR3 2014 Manager Change

Incremental Updates: Send All
WR2 2007 Data Change WR2 2007 Data Change
WR2 2008 Promotion Full Rowset- Send WR2 2008 Promotion
WR2 2009 Termination everything WR2 2009 Termination
WR3 2012 Location Change WR3 2012 Location Change
WR3 2014 Manager Change WR3 2014 Manager Change
WR3 2017 NEW ROW **change WR3 2017 NEW ROW

Incremental Updates: Only the changed WorkRelationship(s)
Employee Data: Source System
Work Effective Action
Relationship Date
WR1 2002 Hire Employee Data: HCM Cloud
WR1 2003 Assignment Change Work Effective Action
Relationship Date
WR1 2004 Salary Change
WR3 2010 Rehire
WR1 2005 Termination
WR2 2006 Rehire
WR3 2012 Location Change
WR2 2007 Data Change
WR3 2013 Promotion
WR2 2008 Promotion Full Rowset- Changed WRs WR3 2014 Manager Change
WR3 2015 Assignment Change
WR3 2010 Rehire
WR3 2016 Promotion
WR3 2017 NEW ROW
WR3 2013 Promotion
WR3 2014 Manager Change
WR3 2016 Promotion
WR3 2017 NEW ROW **change
Incremental Updates: We are not sending the complete history, instead

sending data only for the changed work relationship(s).

Incremental Updates: Only the changed transaction(s)
Relationship Date
WR1 2002 Hire
WR2 2006 Rehire
WR2 2007 Data Change Employee Data: HCM Cloud
WR2 2008 Promotion Partial Rowset-True Delta Relationship Date
WR2 2009 Termination WR3 2017 NEW ROW
WR3 2010 Rehire
WR3 2013 Promotion
WR3 2016 Promotion

Employee Data Load
• Use Case: Partial History – Shell data
3. Only the changed transaction (partial rowset)

What is the “Shell” of the data?
Employment History Shell\Skeleton
WR1 2003 Assignment Change WR1 2005 Termination
WR1 2004 Shell WR2 2006 Rehire
Salary Change
WR2 2008 Promotion
WR3 2010 Rehire
WR3 2011 Salary Change • If you don’t load the shell data, instead decided to load employment data starting say year
WR3 2012 Location Change 2015, there is no easy way to convert historical-data at later date.
WR3 2013 Promotion
WR3 2014 Manager Change • Instead if you load the shell data, you can always come back load that historical data at later
WR3 2015 Assignment Change date.
WR3 2016 Promotion
WR3 2017 Assignment Change • Why to use Shell data approach?
– You want to load minimal data now and go live with phase1, few months down the line come back and insert more
historical data.
– You want to start with coexistence first, load minimal data now and later during full HCM implementation convert entire
history.
• Bottom-line: HDL does allow you to insert rows in-between for the work relationship which is
already loaded, but in future if you decide to load prior\historical work relationships then the
only easy way to make that happen is by loading shell to being with….

Converting Partial History-Shell Data
One-time Conversion
Salary Change
WR2 2007 Data Change WR3 2011 Salary Change
WR2 2008 Promotion WR3 2012 Location Change
WR2 2009 Termination WR3 2013 Promotion
WR3 2010 Rehire WR3 2014 Manager Change
WR3 2011 Salary Change WR3 2015 Assignment Change
WR3 2012 Location Change WR3 2016 Promotion
WR3 2013 Promotion
Full Rowset- for active WR only WR3 2017 Assignment Change
WR3 2016 Promotion
One time Conversion: Shell + the full rowset of the active WR

Salary Change
WR2 2007 Data Change WR3 2011 Salary Change
WR2 2008 Promotion WR3 2012 Location Change
WR2 2009 Termination WR3 2013 Promotion
WR3 2010 Rehire WR3 2014 Manager Change
WR3 2013 Promotion
Full Rowset- for changed WR WR3 2017 Assignment Change
WR3 2014 Manager Change WR3 2017 NEW ROW
WR3 2016 Promotion
Incremental Updates: Send All i.e. Shell + the full rowset of the changed WRs

Relationship Date
Relationship Date
WR3 2010 Rehire
WR2 2006 Rehire
WR3 2013 Promotion
WR2 2008 Promotion Full Rowset- Changed WRs WR3 2014 Manager Change
WR3 2010 Rehire
WR3 2016 Promotion
WR3 2017 NEW ROW
WR3 2013 Promotion
WR3 2016 Promotion
Incremental Updates: We are not sending the complete shell, instead


Relationship Date
WR1 2002 Hire
WR2 2006 Rehire
WR2 2008 Promotion Partial Rowset-True Delta Relationship Date
WR2 2009 Termination WR3 2017 NEW ROW
WR3 2010 Rehire
WR3 2013 Promotion
WR3 2016 Promotion

Employee Data Load
• Use Case: Partial History – Cut-off date

Converting Partial History: Cut-off date
What is cut off date?
Relationship Date
WR1 2002 Hire
WR2 2006 Rehire
e.g. Cut-off date is Jan1st 2015.
WR2 2008 Promotion
Requirement is to load the data on\after the cut off date.
WR3 2010 Rehire
WR3 2011 Salary Change ** Please note: If you chose today’s date\go live date\some recent date as cut off
WR3 2012 Location Change date then many of the employee’s may not even have employment data row
WR3 2013 Promotion on\after the cut off date. We will talk about this option as part of “top of the
WR3 2014 Manager Change stack” discussion.
WR3 2016 Promotion **In current use case, lets work with assumption that cut-off date is selected such
WR3 2017 Assignment Change that every employee has some employment history on\after that date.

One-time Conversion
Relationship Date
WR1 2002 Hire
WR1 2004 Employee Data: HCM Cloud
Salary Change
WR1 2005 Termination Relationship Date
WR2 2006 Rehire WR1 2002 Hire
Shell
WR2 2008 Promotion WR2 2006 Rehire
WR3 2013 Promotion Cutoff: Jan 1-2015
WR3 2014 Manager Change Full Rowset- for active WR only
WR3 2016 Promotion
e.g. cut-off date 2015.

One time Conversion: Shell + the full rowset of the active WR but only with the
transactions after the cut off date
Relationship Date
WR1 2002 Hire
WR1 2004
Employee Data: HCM Cloud
Salary Change
WR2 2007 Data Change Shell WR1 2005 Termination
WR3 2013 Promotion
Cutoff: Jan 1-2015
WR3 2014 Manager Change Full Rowset- for changed WR WR3 2017 NEW ROW
WR3 2016 Promotion
Incremental Updates: Send All i.e. Shell + the full rowset of the changed
WRs but only with the transactions after the cut off date

Relationship Date
Relationship Date
WR3 2010 Rehire
WR2 2006 Rehire
WR3 2016 Promotion
WR2 2008 Promotion Cutoff: Jan 1-2015 WR3 2017 Assignment Change
WR3 2017 NEW ROW
WR2 2009 Termination Full Rowset- Changed WRs
WR3 2010 Rehire
WR3 2013 Promotion
WR3 2016 Promotion


Relationship Date
WR1 2002 Hire
WR2 2006 Rehire
WR2 2008 Promotion Cutoff: Jan 1-2015 Work Effective Action
Relationship Date
WR2 2009 Termination Partial Rowset-True Delta WR3 2017 NEW ROW
WR3 2010 Rehire
WR3 2013 Promotion
WR3 2016 Promotion

Employee Data Load
• Use Case: Partial History – ‘Top of the stack’

Converting Partial History- ‘Top of the Stack’
Considerations
• Top of the Stack row option should be very similar to the shell data use
cases or cut off date concept. Instead of using a specific cut off date, you
are passing the latest row for the active work relationship. Please refer to
prior two use cases in such scenarios.
• In this section, we will discuss the interesting use case where customers
decide to use point in time\specific date to load latest employee
information. For e.g. everyone will have a row as of June 1st 2016 with
latest employment info, in addition to the shell\hire row and hence you
have the so called top of the stack row with current employment data.

One-time Conversion
Relationship Date
WR1 2002 Hire
WR1 2005 Termination Employee Data: HCM Cloud
WR2 2006 Rehire Work Effective Action
Shell Relationship Date
WR1 2002 Hire
WR2 2008 Promotion
WR2 2006 Rehire
WR3 2010 Rehire
WR3 2010 Rehire
WR3 2013 Promotion Full Rowset- Top of the stack row as WR3 2017 Conversion
WR3 2014 Manager Change of June1st 2017
WR3 2016 Promotion
One time Conversion: Shell + top of the stack row for June1st 2017 with latest
employment info for everyone. In above example, customer has decided to use the
action code of “Conversion” and such row does not exists in the source application.
Relationship Date
WR1 2002 Hire
WR1 2004
Employee Data: HCM Cloud
Salary Change
WR2 2007 Data Change Shell WR1 2005 Termination
WR3 2011 Salary Change WR3 2017 Conversion
WR3 2012 Location Change WR3 2017 NEW ROW
WR3 2013 Promotion
Top of the stack: June 1st 2017
WR3 2014 Manager Change Full Rowset- for changed WR
WR3 2016 Promotion
Incremental Updates: Send All i.e. Shell + the full rowset of the changed
WRs.

Relationship Date
Relationship Date
WR3 2010 Rehire
WR3 2017 Conversion
WR2 2006 Rehire
WR3 2017 NEW ROW
WR2 2008 Promotion Top of the stack: June 1st 2017
WR2 2009 Termination Full Rowset- Changed WRs
WR3 2010 Rehire
WR3 2013 Promotion
WR3 2016 Promotion


Relationship Date
WR1 2002 Hire
WR2 2006 Rehire
WR2 2008 Promotion Top of the stack: June 1st
2017 Work Effective Action
Relationship Date
WR2 2009 Termination Partial Rowset-True Delta WR3 2017 NEW ROW
WR3 2010 Rehire
WR3 2013 Promotion
WR3 2016 Promotion
**change
WR3 2017 NEW ROW

Employee Data Load
• Use Case: Partial History – Basic Worker (0 history records)

Converting Partial History- Basic Worker (0 historical data)
One-time Conversion
Relationship Date
WR1 2002 Hire
WR2 2006 Rehire
WR2 2008 Promotion Single Row Work Effective Action
WR3 2010 Rehire WR3 2010 Hire\Rehire\Conversion
WR3 2013 Promotion
WR3 2016 Promotion

Converting Partial History- Basic Worker (0 historical data)
Incremental Updates: Send All\Changed WR\Changed Transactions etc…
Relationship Date
WR1 2002 Hire
WR2 2006 Rehire
WR2 2008 Promotion Single Row-Correction Work
Relationship
Effective
Date
Action
WR3 2010 Rehire
mode WR3 2010 Hire\Rehire\Conversion
WR3 2013 Promotion
WR3 2016 Promotion

Employee Data Load Incremental: Send Incremental: Incremental:
Recap Complete history
Onetime Conv
All Changed WR Changed Row
Partial History: Shell Data **Recommend?**

Partial History: Cut off
date
Partial History: top of
stack
Partial History: No history
• Recommendations?
• Coexistence Model (no intensions to go for full hcm)
• Start with coexistence, 6months down the line go for FULL HCM?
• Minimal history now, 6months down the line convert more (fill in the gaps)
• Undecided?

HDL Modes
•Retain and Replace

HDL Modes
• HCM Data Loader supports two different update modes that impact how future dated records
are handled:
– Retain - Retains all existing date-effective records.
– Replace - Removes existing date-effective splits for the date range specified.
Mode Replace Retain

Command SET PURGE_FUTURE_CHANGES Y SET PURGE_FUTURE_CHANGES N
Description Removes existing date effective rows for date In retain mode, you can choose to:
range specified •Retain future dated record values without
updating them (#RETAIN)
•Retain future date-effective splits but roll forward
the changed values
When to During data-conversion, when complete object When supplying incremental updates to an existing
Use? data is provided record or cases where partial object data is
provided

HDL Mode- Replace
Example with FULL Rowset\Complete Data
ESD EED Action Code Job Code Grade Code Location Organization
05 MAR 2013 14 AUG 2015 HIRE SE IC1 HQ DEV
15 AUG 2015 PROMOTE SE IC2 HQ DEV
SET PURGE_FUTURE_CHANGES Y
05 MAR 2012 31 JUL 2015 HIRE SE IC1 HQ DEV
In this example, the existing promotion row is deleted and replaced with the new promotion record.

HDL Mode- Retain
Example with FULL Rowset\Complete Data
SET PURGE_FUTURE_CHANGES N
01 AUG 2015 14 AUG 2015 PROMOTE SE IC2 HQ DEV
In this example, existing promotion row is retained and a new split created for the adjusted promotion date.

HDL Mode- Replace
Example with Partial Rowset
SET PURGE_FUTURE_CHANGES Y
01 AUG 2015 PROMOTE SE IC2 PL1 DEV
In this example, the existing promotion row is deleted and replaced with the new promotion record.

HDL Mode- Retain
Example with Partial Rowset
SET PURGE_FUTURE_CHANGES N
01 AUG 2015 14 AUG 2015 PROMOTE SE IC2 PL1 DEV
15 AUG 2015 PROMOTE SE IC2 PL1 DEV
In this example, existing promotion row is retained and a new split created for the adjusted promotion date. Also
the previous location change rolls forward to all future-dated records.

HDL Modes Example: Retain mode & use of #RETAIN tag for effective end date
Use case – Normal working hours changed to 37.5 on Jan

10th 2012
Retain future dated record values without updating Retain future date-effective splits but roll forward the
them changed values
SET PURGE_FUTURE_CHANGES N SET PURGE_FUTURE_CHANGES N

Specify #RETAIN for the effective end date Specify 4712-12-31 or blank for effective end date

HDL Modes What Not To Do
• If you use Replace mode during incremental updates and are sending only the delta rows, it
may result in loss of data. Action is not reversible.
• Partial updates corrupt your Oracle HCM record.
Existing Data
Incoming HDL File
Results

Putting it together…
• HDL Modes (Retain\Replace)
• Row Sets (Full\Partial)

Key Differences- Full vs Partial Rowset + Retain vs Replace
Full Rowset Partial Rowset
If you have sent N rows for an employee during initial conversion then you Even if you have sent N number of rows for an employee during initial
send N+1 rows i.e. full data set during Incremental updates. conversion, you send only the changed row to fusion. (true delta \ partial
data set)
Use Replace mode for HDL - SET PURGE_FUTURE_CHANGES Y Use Retain mode for HDL- SET PURGE_FUTURE_CHANGES N
Full data sets to report incremental changes is not the most optimal method Partial data sets to report incremental changes are more efficient to upload.
to do data upload as there will be lot of data moving around stage records. There is much less data being moved around and imported into stage tables.
(No matter which option you select, incremental updates should only send the data for (No matter which option you select, incremental updates should only send the data for
employees that has changed since last run, as opposed to sending data for all employees) employees that has changed since last run, as opposed to sending data for all employees)
It can handle correction mode changes made for effective dates . It can handle correction mode changes for effective dates but it may result in
having different number of rows as compared to the source system for a
coexistence implementation.
It can handle situations where business users do deletes on employee You may not be able to handle deletes made by business users to employee’s
records. For e.g. HR user deleted a current\historical data row from record esp. in a coexistence implementation.
PeopleSoft Job data.
Easier and cost effective approach, very similar to initial or full data load with Complex and costlier approach to implement Separate programs for initial
exception that during full load you do conversion for entire population, conversion and incremental updates.
where as during incremental mode you send data only for changed
employees.
Recommended approach for Coexistence implementations (**full rowset). Recommended approach for ongoing integrations or coexistence where
business users don’t make correction mode changes or deletes in source
application.

Lesson5-HDL-Full Vs Partial History - PPT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lesson5-HDL-Full Vs Partial History - PPT

Uploaded by

Copyright:

Available Formats

HCM

Data Loader (HDL)

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 2

Incoming Data: Employee was promoted on June 1st 2017

Full Rowset Partial Rowset

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 4

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 5

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 6

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 7

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 8

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 9

Incremental Updates: We are not sending the complete history, instead

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 10

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 11

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 12

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 13

One time Conversion: Shell + the full rowset of the active WR

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 14

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 15

Incremental Updates: We are not sending the complete shell, instead

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 16

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 17

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 18

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 19

e.g. cut-off date 2015.

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 21

Incremental Updates: We are not sending the complete shell, instead

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 22

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 23

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 24

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 25

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 27

Incremental Updates: We are not sending the complete shell, instead

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 28

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 29

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 30

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 31

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 32

Partial History: Shell Data **Recommend?**

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 33

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 34

Mode Replace Retain

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 35

15 AUG 2015 PROMOTE SE IC2 HQ DEV

01 AUG 2015 PROMOTE SE IC2 HQ DEV

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 36

15 AUG 2015 PROMOTE SE IC2 HQ DEV

01 AUG 2015 14 AUG 2015 PROMOTE SE IC2 HQ DEV

15 AUG 2015 PROMOTE SE IC2 HQ DEV

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 37

15 AUG 2015 PROMOTE SE IC2 HQ DEV

01 AUG 2015 PROMOTE SE IC2 PL1 DEV

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 38

15 AUG 2015 PROMOTE SE IC2 HQ DEV

01 AUG 2015 14 AUG 2015 PROMOTE SE IC2 PL1 DEV

15 AUG 2015 PROMOTE SE IC2 PL1 DEV

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 39

Use case – Normal working hours changed to 37.5 on Jan

SET PURGE_FUTURE_CHANGES N SET PURGE_FUTURE_CHANGES N

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 40

Incoming HDL File

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 41

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 42

Partial History: Shell Data Recommend?