WFC70_RecordMgrUserGuide

Record Manager

User Guide

A comprehensive guide for users and administrators of Record Manager.

Kronos Workforce Central suite version 7.0

Document Revision History

The information in this document is subject to change without notice and should not be construed as a commitment by Kronos Incorporated. Kronos Incorporated assumes no responsibility for any errors that may appear in this manual. This document or any part thereof may not be reproduced in any form without the written permission of Kronos Incorporated. All rights reserved. Copyright 2013.

Altitude, Altitude Dream, Cambridge Clock, CardSaver, Datakeeper, Datakeeper Central, eForce, Gatekeeper, Gatekeeper Central, Imagekeeper, Jobkeeper Central, Keep.Trac, Kronos, Kronos InTouch, Kronos Touch ID, the Kronos logo, My Genies, PeoplePlanner, PeoplePlanner & Design, Schedule Manager & Design, ShiftLogic, ShopTrac, ShopTrac Pro, StarComm, StarPort, StarSaver, StarTimer, TeleTime, Timekeeper, Timekeeper Central, TimeMaker, Unicru, Visionware, Workforce Accruals, Workforce Central, Workforce Decisions, Workforce Express, Workforce Genie, and Workforce TeleTime are registered trademarks of Kronos Incorporated or a related company. Altitude MPP, Altitude MPPXpress, Altitude Pairing, Altitude PBS, Comm.Mgr, CommLink, DKC/Datalink, eDiagnostics, Experts at Improving the Performance of People and Business, FasTrack, Hireport, HR and Payroll Answerforce, HyperFind, Kronos 4500 Touch ID, Kronos 4500, Kronos 4510, Kronos Acquisition, Kronos e-Central, Kronos KnowledgePass, Kronos TechKnowledgy, KronosWorks, KVC OnDemand, Labor Plus, Momentum Essentials, Momentum Online, Momentum, MPPXpress, Overall Labor Effectiveness, Schedule Assistant, Smart Scheduler, Smart View, Start Quality, Start WIP, Starter Series, StartLabor, TeleStaff, Timekeeper Decisions, Timekeeper Web, VisionPlus, Winstar Elite, WIP Plus, Workforce Absence Manager, Workforce Acquisition, Workforce Activities, Workforce Analytics, Workforce Attendance, Workforce Central Portal, Workforce Connect, Workforce Employee, Workforce ESP, Workforce Forecast Manager, Workforce HR, Workforce Leave, Workforce Manager, Workforce MobileTime, Workforce Operations Planner, Workforce Payroll, Workforce Record Manager, Workforce Recruiter, Workforce Scheduler, Workforce Smart Scheduler, Workforce Task Management, Workforce Tax Filing, Workforce Timekeeper, Workforce View, and Workforce Worksheet are trademarks of Kronos Incorporated or a related company.

The source code for Equinox is available for free download at www.eclipse.org.

All other trademarks or registered trademarks used herein are the property of their respective owners and are used for identification purposes only.

When using and applying the information generated by Kronos products, customers should ensure that they comply with the applicable requirements of federal and state law, such as the Fair Labor Standards Act. Nothing in this Guide shall be construed as an assurance or guaranty that Kronos products comply with any such laws.

Published by Kronos Incorporated297 Billerica Road, Chelmsford, Massachusetts 01824-4119 USA

Phone: 978-250-9800, Fax: 978-367-5900Kronos Incorporated Global Support: 1-800-394-HELP (1-800-394-4357)

For links to information about international subsidiaries of Kronos Incorporated, go tohttp://www.kronos.com

Document Revision Product Version Release Date

A Workforce Central 7.0 June 2013

Contents

Chapter 1: OverviewTypes of data ................................................................................................. 6Archiving data ............................................................................................... 7

Record Retention Policies ....................................................................... 7Copy, Purge, and Archive ....................................................................... 8Accessing archived data .......................................................................... 8

Copying setup data ...................................................................................... 10Using Setup Data Manager ................................................................... 10

Chapter 2: Archiving DataUnderstanding the archive processes ........................................................... 12

Copy All Data ....................................................................................... 13Retroactive copy ................................................................................... 14Purge ..................................................................................................... 14Archive .................................................................................................. 16

Accessing archiving components ................................................................ 17User accounts ........................................................................................ 17Access control points ............................................................................ 19

Determining your archiving strategy ........................................................... 20How much data to archive .................................................................... 20Approaches to archiving ....................................................................... 21Maintaining accurate accruals and holiday credits ............................... 24

Archiving best practices, maintenance, and troubleshooting ...................... 28Best practices ........................................................................................ 28Maintenance .......................................................................................... 35Turn off background processes on the archive system ......................... 38Troubleshooting .................................................................................... 39

4

Chapter 3: Accessing Archived DataGranting access to archived data ..................................................................46Locating and accessing archived data ..........................................................48

Viewing data during an archiving process ............................................49Switching databases ...............................................................................49Combining databases .............................................................................50

Using Setup Data Manager ..........................................................................52How it works ................................................................................................53Setup Data Manager user interface ..............................................................54Transferring setup data .................................................................................55

Last Run Log report ...............................................................................63

Appendix A: Rules and GuidelinesQuick ReferenceGeneral guidelines ........................................................................................66Rules for archiving data ...............................................................................68

Appendix B: Supported dataArchive processes ........................................................................................72Setup Data Manager .....................................................................................75

Appendix C: Customizing the appearance of archived data

Appendix D: Record Types and Tables

Glossary

Chapter 1

Overview

The archiving product enables authorized users to copy data from one suite product database (the source) to another (the target). Use the archive functions of the archiving product to archive user data. Use the Setup Data Manager to copy setup data from one database to another.

This chapter provides an overview of the archiving product: Types of data on page 6 Archiving data on page 7 Copying setup data on page 10

Chapter 1 Overview

6

Types of data

The archiving product treats data differently according to type. The following types of data are stored in a system database: Setup dataData that is supplied during installation or entered by users in

Setup to configure the suite product, such as access profiles, work rules, pay codes, and labor level entries. Setup data is also referred to as non-historical data.

Setup data (Incremental)Same as Setup data, however, with incremental data, the database keeps track of data that is New or Changed.Setup data (Incremental) is also referred to as non-historical incremental data.

People dataAll the information that makes up a People record, such as primary account, badge number, employee status, and assigned profiles. People data is also referred to as non-historical data.

Transaction dataData resulting from an actual or scheduled user event or a totalization. User events include entering punches, performing an account transfer, or approving a timecard. An employees scheduled hours are also considered transaction data. Transaction data is also referred to as historical data.

The archiving product can copy some or all of these types of data from a source to a target database, depending on the type of process you use.

Archiving data

7

Archiving data

When you archive data, you copy data within a range of dates from one system database to another. The copied data is then removed from the database that it was copied from. Archiving data: Minimizes the amount of disk space required for your production database. Reduces the time and resources required for database maintenance. Optimizes the performance of the production system.The archived data remains accessible to authorized users in much the same way as data on the production database, except that archived data is read only.

Important: Record Manager is not designed or supported to provide full backups or copies of databases. Archival operations normally include only the appropriate subset of the full database contents. You should use your database utilities to create full copies and backups of databases. If you want to move system setup data, use the Setup Data Manager.

Record Retention Policies

You can manage data by using a Record Retention Policy. Record Retention Policies define how long to keep certain types of records in the database. The policy assigned to a record type determines how long the records are retained: Forever Records are never removed (the default). Limited Records are subject to deletion from the database after a certain

number of days and are not archived. Delete using Run Limited Policy Now. Archive (requires a license) Records are copied to the target database when

you perform a Copy. Records are deleted when you perform a Purge.In Workforce Central > Record Retention > Retention Policies, if you do not select the way you want your Record Types to be handled, the data will not be handled the way you intended.

Chapter 1 Overview

8

You may also choose not to Archive or Purge your records so that some items remain in production indefinitely.For more information about Record Retention Policies, refer to the suites online Help.

Copy, Purge, and Archive

The main archiving processes are:

You can view the progress of these processes using the archiving Monitor. The Monitor shows the status and the table-by-table progress of the current process, as well as any error messages. When the process completes, the results are posted in Results.

Accessing archived data

The Locator Editor and the Record Locator identify and access data that has been archived: Record LocatorLets users access databases that contain archived data. Locator EditorMaintains the Record Locator; information stored in the

Locator Editor populates the Record Locator. Any time you successfully copy (using Copy All or Archive) information to an archive database, the name of the database and the range of dates that have been

Process Description

Copy Copies a specified amount of data, based on a date range, from a source database to a target database.

Purge Permanently removes a specified amount of transaction data, based on a date range, from a source database.

Archive Copies all data from a source database to a target database and then removes that same data from the source database. Archive is a single process that includes a Copy followed directly by a Purge.

Archiving data

9

copied are automatically added to the Locator Editor on the production database. In the Locator Editor, you add the URL for the system server that points to that database. Once you save the entry, it becomes available in the Record Locator. Later, use the Record Locator to access the archived data.

Chapter 1 Overview

10

Copying setup data

The Setup Data Manager lets you copy setup data from one database to another. Setup data is data that you enter as part of the configuration of the suite. For example, setup data includes pay rules, labor levels, and manager summaries. You can copy all setup data or select specific setup data (referred to as policies). For a complete list of setup data supported by Setup Data Manager, see Setup Data Manager on page 75. Use Setup Data Manager to: Save the time of manually re-entering setup data on multiple databases. Eliminate the potential for a user to make a mistake when re-entering setup

data. Allow you to update a number of setup data policies all at once.

Note: You cannot use Setup Data Manager to copy all setup data. For information about copying data that is not supported, refer to Transferring setup data on page 55.

Using Setup Data Manager

Setup Data Manager is a separately installed component of the archiving product. Setup Data Manager uses the system programming interfaces (APIs) to copy setup data from one database to another. For example, use Setup Data Manager to copy setup data that has been created and tested on a test or development database, to a production database. To copy setup data, select the system servers that point to a source and a target database, and then choose the setup data items. Each item represents a different piece of setup data. The items are uniquely identified by name. If an item is copied to a target database that already contains an item of the same name, the existing item is updated. If an item of the same name does not exist on the target database, the item is added. Items that exist on the target database, but not in the source, are not affected by Setup Data Manager (that is, they are not deleted from the target database).

Chapter 2

Archiving Data

This chapter describes how to archive data using the archiving product: Understanding the archive processes on page 12 Accessing archiving components on page 17 Determining your archiving strategy on page 20

Archiving best practices, maintenance, and troubleshooting on page 28

Chapter 2 Archiving Data

12

Understanding the archive processes

Copy All Data, Purge, and Archive are the processes used for archiving data. The following table shows how these different processes affect the different types of archiving data.

Note: Another type of data is managed by the archiving products Record Retention Policies. This data can become disposable after a certain amount of time. You can edit your retention policy to retain the data forever, to keep it for a limited length of time, or to archive it along with the rest of the archiving product data whenever you run an Archive process. For more information about Record Retention Policies, refer to the suites online Help.

Copy All Data overwrites, or replaces, non-historical data and adds to historical data on the target database. The only exception to this rule is that People who are deleted from a source database after they have been copied to a target database

Data Type Copy All Data Purge ArchiveSetup data and People data(non-historical data)

Data overwrites same data in the target database.

Data is not deleted from the source database.

Data overwrites same data in the target database and is not deleted from the source database.

Transaction data(historical data)

Data is added to data already in the target database.

Data is deleted from the source database.

Data is added to data in the target database and is deleted from the source database.

Setup data (incremental)

Data overwrites same data in the target database, if it changed.

Data is deleted from the source for specific tables.

Data overwrites same data in the target database, if it changed. Data is deleted from the source for specific tables.


13

will not be removed from the target database the next time a copy is run. This preserves the integrity of the archived data for that employee.

Note: The date range that you Copy, Purge, or Archive must be payroll locked.

A description of each process follows. For information on when to use Copy All Data and Purge versus an Archive, refer to Determining your archiving strategy on page 20.

Copy All Data

The Copy All Data process duplicates a set of data onto a target database. The set of data is all the data on the source database within the date range that you provide. In the following example, you have three years worth of data on the production database and you copy the third year to an empty, non-production database. When the Copy process is completed, the third year of data resides on both the production and non-production databases.

Caution: Do not delete an employee while a Copy job is in process. This includes all the time between the start and end of the process, including the time that the process is paused.


14

Retroactive copy

Retroactive Copy copies data that the archiving product has not previously copied. For example, retroactive copy copies Scheduler data that was not supported by the archiving product in previous releases, but is now supported. Run a retroactive copy only once for a set of source and target databases and it will copy data not previously supported to the target database. Once the data has been copied, it does not need to be copied again. If you attempt to run another retroactive copy for the same source and target databases, you will receive an error message indicating that no retroactive copy is required between the source and target databases, and the retroactive copy will not be run.

Purge

After you copy data, you can purge the original data from the source database, either entirely or partially. For example, if you want some of the data to remain on the source database, you do not have to purge the entire range of data that was copied. Purge permanently removes employee transaction data, but leaves setup data and people data intact.

Note: Unless you have access to Purge Override, you can only purge previously copied data.

In the following example, data for year number three has been copied from the production database to a non-production database. Using Purge, the data for year three is removed from the production database.


15

Purge with Purge Override Access Control

Caution: It is strongly recommended that you back up your source database before performing this procedure. Using Purge with the Purge Override access control allows you to permanently erase data before it has been copied.

If you have data that you no longer need, and you want to remove it permanently from the database without copying it, you can do so using Purge, if you have Purge Override access. The only user account with default access to Purge Override is SuperUser.With this override, the purge process removes data even if it has not been copied. For example, you have eight years worth of data and are legally required to keep only seven years worth of data. Therefore, you might choose to purge the oldest year without saving a copy. Purge All

Note: If Schedule Inheritance is enabled before a Purge All operation, employees who are members of the inheriting schedule groups should inherit their schedules from the Schedule Group. However, after a Purge All operation, running Shift Builder does not build out the appropriate schedules for employees based on the current configuration. To correct this situation, add the employees back into the same scheduling group and their schedules will be build out properly.

Users with Purge Override access can also choose to Purge All, which deletes all transaction data from a database. Data does not need to be payroll locked to be purged using Purge All. Therefore, to prevent errors, it is important that you do the following before using Purge All: Stop the timekeeping products Background Processor. Disable Event Manager:

Disable all events, including Shift Builder, using the Event Manager. Choose Setup > Common Setup > Event Manager.

Disable the Event Manager. Choose Setup > System Configuration > System Settings; then click the Event Manager tab. Set the site.eventmanager.enabled property to false.


16

Restart the system server. Also, make sure that no system events that started before you disabled Event Manager are still running.

Disconnect all system users. Stop the Device Manager, if applicable.

Archive

The Archive process is a single process that performs a Copy and then a Purge on the same range of dates. The information that is copied from the source to the target database is purged from the source database immediately after the copy. the start date for the archive process defaults to the date of the first timesheet entry or accrual transaction in the source database, whichever is earlier. It also looks at the employees schedules and POS data, such as schedule or punch data. This date cannot be changed. The end date can be set to any date contained on the source database that is after the start date. Because the start date for the archive process is the earliest date found on the source database, the archiving product attempts to copy again any information that has previously been copied, but not yet purged. However, the same information cannot be copied to the same target database twice. Therefore, if you run the Copy process without performing a Purge and then attempt to run an Archive process using the same target database, you will receive an error and the process will not run. If you want to run an Archive process after having performed a Copy, you need to either purge the previously copied data from the source database or choose an empty non-production database as the target database for the Archive process.

Note: The same information can be copied to the same target database twice if the target database has been purged of the previously copied data using the archiving product.

Caution: Do not delete an employee while an Archive job is in process. This includes all the time between the start and end of the process, including the time that the process is paused.

Accessing archiving components

17


Access to the archiving product is controlled by access control point settings that are saved as part of a function access profile in Setup. Function access profiles with particular settings are then assigned to individual users, depending on their job.

User accounts

The SuperUser user account is the highest-priority user account that the system administrator uses. The functionality available to the SuperUser user account is determined by the Super Access function access profile, which gives the SuperUser access to every function. A limited number of users should know of and use this account.The ArchiveIS and ArchivePayroll user accounts are delivered as part of the data with every database build. They are the most useful accounts for accessing the archiving product. These accounts have default passwords and, with the exception of the password, none of the information that makes up these accounts can be changed. The functionality available to the ArchiveIS and ArchivePayroll user accounts is determined by the two function access profiles created for the archiving product. The ArchiveIS account is assigned the ArchiveIS function access profile, and the ArchivePayroll account is assigned the ArchivePayroll function access profile. In general, the ArchiveIS profile grants access to more functionality in both the System Configuration and the archiving product components than the ArchivePayroll profile. The following tables show the functionality allowed with the archiving product.


18

User accounts and access control point settings

User account profile settings

Access Control Point SuperUser ArchiveIS ArchivePayroll

Archiving ProductArchiving product access Allowed Allowed NonePurge Override Allowed None NoneCancel Allowed Allowed NoneRecord Locator Allowed Allowed AllowedLocator Editor Allowed Allowed NoneDelete Database Allowed Disallowed None


19

Access control points

You may determine that the default function access profiles grant more access than some of your users need. For that reason, you might want to customize the archiving product-specific access control point settings yourself. To do so, you will have to edit one of your existing function access profiles or create a new one because the ArchiveIS and ArchivePayroll function access profiles cannot be edited. The following table details the archiving product access control points.

Note: These settings do not control access to archive databases or Setup Data Manager. You grant accounts access to archive databases using the People Editor. For more information, refer to Granting access to archived data on page 46. Access to Retention options is described in the suite user guide.

Access Control Point Description

Archiving product access Controls top-level access to the archiving product functionality, including the Copy, Purge, and Archive processes, the Pause and Resume process controls, and the archiving Results and Schedule components.This access control point controls access to all of the other archiving products access control points.

Purge Override Allows the user to execute a Purge process on data that has not been copied or payroll locked.

Cancel Allows the user to cancel an in-process or paused archiving process (that is, a Copy, Purge, or Archive).

Record Locator Allows a user access to the Record Locator screen, which provides the user direct access to databases that contain archived data.

Locator Editor Allows a user to configure information that allows users to access, through the Record Locator, databases that contain archived data.

Delete Database Allows the user to delete databases that are no longer in use.


20

Determining your archiving strategy

Your archiving strategy is determined by your requirements for data retention, your needs for data access, and your available resources. Your archive strategy dictates how much data you archive and the approach you use for archiving. This section discusses these two topics in relation to your requirements, needs, and resources.

How much data to archive

One of the most important considerations when you choose an archive strategy and determine the resources that it requires, is the amount of data to keep on your production database versus your archive database(s). Several factors affect this decision: Legal requirements/company policyAddress any legal or labor union

rules for data retention, as well as company policy. For example, a law may require you to retain at least 7 years of data.

Frequency of accessKeep your most frequently accessed data in the production database. How often to payroll and department managers need to access older data? If your archive databases are difficult to access, for example, they are not connected to system servers, you will want to be especially careful about archiving frequently accessed data.

Note: Data within the last three pay periods is accessed quite often. Data within the last 12 months is the second most frequently accessed set of data, while data older than two years tends to be accessed infrequently.

Accuracy of accruals informationKeep enough data in both the production and non-production databases to ensure that accurate accruals information exists for all dates. For more information, refer to Maintaining accurate accruals and holiday credits on page 24.


21

Reporting needsKeep the data that you most frequently use for a single report on a single database; for example, a calendar year.

Note: The single database may or may not be your production database. For example, you might choose to generate from a non-production database all of the reports that you run against past pay periods.

Approaches to archiving

Your approach to archiving depends on how much data you are archiving and your available resources. For example, if you have a server available to act as a non-production system server for running the archiving processes, it will reduce the load on your production environment. Another factor is the amount of time and expertise your IS department has to run archiving processes.The three common approaches to archiving are described in this section. One of these approaches, or some variation, is a good starting point for using the archiving product. As you become more familiar with the software and more aware of how it can benefit your organization, you may choose to alter your strategy.

Copy and Purge Infrequently

For example, you keep the three most recent years worth of data on your production database and archive previous years. On an infrequent basis (yearly), you copy data that is more than three years old to a non-production database and then purge the production database. This strategy produces the following:Advantages Balances the demands on your time and resources by keeping frequency

low and a reduced amount of data in the production database. Recent data is available online for easy access.


22

Disadvantages Possible increases in time and effort to generate reports because some

data is on the production database and some is on a non-production database.

Accruals can be affected if you archive incorrect dates. The larger the block of time that you Copy or Purge, the longer the

process takes to complete.

Copy Frequently and Purge Infrequently

For example, you copy data to a non-production database at the end of each pay period, but you do not purge it at that time. You purge the production database annually. This strategy produces the following:Advantages Up-to-date data on the non-production database, which enables reports for

multiple years from a single database. Reduced amount of data on the production database. All data is online for easy access. Overlapping dates on source and target database allow for accurate totals

on both. Small time period takes a short time to copy. Disadvantages More disk space is required to keep duplicate data in two databases. Resources are required to perform and monitor frequent copying. The Purge at the end of the year may take a long time.


23

Use Archive to Copy and Purge Data in One Step

The one-step Archive process is described in earlier in this guide. This strategy produces the following: Advantages The ability to schedule a single process to copy and purge data. Uses less disk space because there is no overlapping data on the source

and target databases.Disadvantages Does not allow for data overlap between the source and target databases,

which is required for accurate totals if you are using accruals. Possible increases in time and effort to generate reports because some

data is on the production database and some is on a non-production database.

When to Use Copy and Purge instead of Archive

The Archive process performs a Copy and a Purge consecutively in one two-step process. However, you may want to use a Copy and a Purge separately, for the following reasons: To reduce the frequency of long-running processesOn Oracle databases,

purging data takes more time than copying data. So, you might choose to copy frequently and purge less frequently. Or, you might choose to copy a large amount of data and then purge data in smaller blocks.

To meet your needs for single reportsYou may want to copy data to a target database for the purpose of running a single report against a range of dates that does not exist on your production database. You may not want to purge all the data that you copy.


24

To guarantee that accurate accrual balances exist for all users and for all datesIn order for accrual balances to be accurate for all dates, you must overlap data on the source and target database as described in Maintaining accurate accruals and holiday credits on page 24. Overlapping data calls for purging less data than you copy.

To prepare your source or target database for an Archive processIf you have performed a Copy without purging, the Archive process will not work with the same target database used for the Copy until you remove the previously copied data from the source or the target database, using the Purge process. For more information about this, see Archive on page 16.

Review Record Retention Policies

Review your Record Retention Policies in Workforce Central in Record Retention > Retention Policies to review your settings and determine whether they are set appropriately to Archive, Purge, or maintain your records.

Maintaining accurate accruals and holiday credits

Qualifiers

If you use holiday credits or calculated accruals with qualifiers, you need to ensure that you keep enough data on the production database to check for eligibility and grant accruals and holiday credits where appropriate. For example, if you require an employee to have worked a certain number of hours in the last 90 days in order to earn a holiday, you need at least 90 days worth of payroll data on your production system in order to verify that the employee has worked that number of hours. Assume that Jack Smith was hired on April 4, 2005 and the next holiday for which he is eligible to receive a holiday credit is July 4, 2005. If you purged data from April 1 to July 1, 2005, the system determines that Jack is not eligible to receive the holiday credit for July 4 because the data showing his hours over the last 90 days no longer exists.


25

Refer to your holiday credit and accruals rules and keep an amount of historical data on your production database equal to the length of your longest qualifier. This will ensure that all employees are properly qualified when necessary.

Note: If you attempt to purge data from a database that contains accruals information, a message box appears indicating that purging too much data may adversely affect accruals calculations.

Accrual Balances

Accrual balances are saved in the accruals table at the end of a signed-off pay period or after an import, depending on whether you use calculated or imported accruals. With calculated accruals, this balance is the basis for calculating ongoing accruals. For imported accruals, this balance is the balance that appears in the user interface until the next import. Any dates that exist in a database before the first pay period sign-off or accruals import will show incorrect accruals information, because there is no defined starting point from which to base the incremented balances. This can happen on a production database after you purge data, given the likely scenario that you will not purge up to the exact date of a sign-off or import. To ensure that accurate accruals information exists for all past dates on at least one databaseeither your production database or the non-production database to which you copy datait is strongly recommended that you overlap the dates contained on the databases by the length of your longest pay period or accruals import interval. This guarantees that any dates that include inaccurate accruals information on the production database are accurate on the non-production database. For example, assume that your company uses calculated accruals and you want to archive data from January 1, 2005 to May 1, 2005. If your longest pay period is two weeks, your overlap strategy is: Copy data from January 1 to May 15, 2005. You have added the length of your

pay period to your planned range of dates. Purge data from January 1 to April 15, 2005. You have subtracted the length

of your pay period from your planned range of dates.


26

Note: To overlap data on your source and your target database, you need to use the separate Copy and Purge processes rather than the one-step Archive process, because you need to specify a different range of dates for Copy than for Purge.

If your employees use more than one pay period, use the longest one to determine your overlap strategy.

Overlap strategy if you use calculated accruals

When copying, copy a range of dates that is longer than the data that you want to copy by the equivalent of your longest pay period.

When purging, purge a range of dates that is shorter than the data that you copied by the equivalent of your longest pay period.

Overlap strategy if you use imported accruals

When copying, copy a range of dates that is longer than the data that you want to copy by the equivalent of your longest import interval.

When purging, purge a range of dates that is shorter than the data that you copied by the equivalent of your longest import interval.

Where to look for accurate accruals information

When you use the overlap strategy: Accruals information is guaranteed to be accurate on the non-production

database for all dates that have been copied to that database, assuming those dates are after a pay period sign-off or accruals import date contained on the non-production database.

For dates that have not been copied, the accruals information is guaranteed to be accurate on the production database, assuming that you have enough history on the database to satisfy the qualifiers for the accruals.

To find out what dates have been copied to or from a database, look in the Record Locator or Locator Editor.


27

Note: Due to the nature of Projected Accrual Balances, they do not calculate accurately on a non-production database containing archived data regardless of your archiving strategy.


28

Archiving best practices, maintenance, and troubleshooting

This section contains best practices, maintenance advice, and troubleshooting information for archiving data. Follow the instructions in this section to create the most productive archiving environment. For a complete collection of rules and guidelines that will help you avoid problems, refer to Appendix A, Rules and GuidelinesQuick Reference, on page 65.

Best practices

Best practices are ways of using the archiving product to achieve the best results. Follow the instructions in this section to maximize the performance of the product and to minimize the time spent troubleshooting problems.

Prepare your databases

You can optimize the performance of the archiving product by preparing your databases before you start a Copy, Purge, or Archive process. To prepare your databases: Run the Reconcile utility on the source and target databases (or, only on the

source database for a Purge): Fix any errors that are reported during the reconcile before you run an archiving process. Missing database objects can affect the integrity of the data that is being copied or purged.

Update statistics on the source and target databases.


29

Back Up Your DatabasesUse the following guidelines to determine what database(s) to back up and when: Before a Copy, back up your target database. Before a Purge, back up your source databases. Before an Archive, back up your source and your target database. After a Copy, back up your source, your target, and your production

database. After a Purge, back up your source and your production database. After an Archive, back up your source, your target, and your production

database.

Manage your resources

The archiving product requires processor power and memory to copy and purge data between databasespower and memory that are valuable resources in your production environment. In order to minimize the amount of resources borrowed from the production environment during an archiving process, you can schedule processes for off-peak hours and/or run processes on a non-production server. To estimate the time required for different archiving processes and the impact of different settings and resources on that time, set up an archiving product test environment. Schedule processes for off-peak hours

Off-peak hours are the hours when activity on your production database is at its lowest. Schedule archiving processes to run during these hours to maintain the performance of your production environment while making use of the untaxed resources during the less active hours. To set up processes to run during off-peak hours only, schedule Pause and Resume controls around your peak usage hours, such as the hours when payroll is processed. This will prevent a process from running during those peak usage hours and force it to run during off-peak hours.


30

For example, if you never want an archiving process to run between the hours of 9:00 A.M. and 12:00 P.M., you can schedule a Pause at 9 and a Resume at 12 that will temporarily stop and then restart the process. Schedule pauses and resumes around all peak-usage periods. If a process has completed or is not running, any scheduled Pause or Resume is ignored.

Note: A pause scheduled at 9:00 A.M. and a resume scheduled at 12:00 P.M. does not prevent a process from starting between the hours of 9 A.M. and 12 P.M. The only way to do that is to make sure that you never schedule a process to start or manually start a process between those hours.

With pauses and resumes scheduled around all peak usage hours, an archiving process might take longer to run, but it will never borrow resources from more critical processing jobs.

Note: If you use Oracle databases and are able to run Purges while the system is in offline mode, you can improve the performance of each Purge by increasing the values of the sort_area_size and sort_area_retained_size parameters in the init.ora configuration file. The exact value for each parameter depends on the amount of memory that is available on the server. Before starting the Purge, shut down and restart the Oracle instance, to make these changes take effect. Both parameters should be set back to the original values after the Purge is complete and before you bring the system back on line.

Use a test environment

The time required to complete an archiving process depends on the specific characteristics of your database, such as, the number of employees, the amount of history, and the amount of activity on the database. For that reason, it is difficult to estimate how long a process will take or to specify minimum resources for running a process in your environment. Creating a test environment for the archiving product is the best way to estimate the time and resources necessary to run a Copy, Purge, or Archive process. The archiving product test environment should reflect your production environment as accurately as possible. The most important variables in determining a time estimate for a process are: processor speed, number of processors, memory, and overall workload for the servers. You may want to test


31

with different hardware configurations and validation settings to determine which use your resources most efficiently. Your test environment is also a good place to test different archiving strategies and scheduling methods (including Schedule processes for off-peak hours).

Drop indexes

You can speed the performance of an Archive or Copy job by choosing to drop table indexes from the target database before copying data. By default, the indexes that get dropped are those indexes belonging to the largest tables in the database. Once the indexes are dropped, not only does the speed of the copy increase, but the time spent rebuilding the indexes after each table is copied is eliminated (you can configure the archiving product to rebuild the indexes after all the tables have been copied). If you are going to drop indexes from the target database, it is recommended that you set the archiving product to rebuild the indexes after the copy. Because the indexes are rebuilt after the copy, the target database is the only database affected by the processing. The archiving product is not required to keep a connection open to the production database during this time, as it would if the indexes were being maintained during the copy. This reduces the overall load on the production database. To drop indexes from the target database before copying data:1. Choose Setup > System Configuration > System Settings and click the

Record Retention - Options & Tuning tab. 2. Set the value of WrmSetting.Option.DropTargetIndexes to

true. 3. Set the value of WrmSetting.Option.RebuildTargetIndexes to

true so that these indexes are rebuilt after the copy. To edit the list of indexes that are dropped and rebuilt using the above options: 1. Choose Setup > System Configuration > System Settings and click the

Record Retention - Options & Tuning tab. 2. Add or remove table index names from the list of indexes in the

WrmSetting.Option.IndexList setting.


32

Note: By default, this list includes table indexes that result in the greatest gain in performance when dropped from the target database. Your specific suite application may result in other tables growing to such a size where dropping them is advisable.

Use notifications and the system log

The archiving product provides information about processes in two ways: through the use of automatic e-mail notifications and through the system log files. The e-mail notifications keep you informed about the status of archiving processes, and the log provides you with valuable information for troubleshooting. Use e-mail notifications

You can configure the archiving product to send out e-mail notifications at the start and/or end of a process, similar to other system notifications. If you do not have Workflow Notifications configured on the system server from which you run the archiving product, but you would like to use the e-mail notifications, perform the following steps:

Note: If you have Workflow Notifications configured on the server from which you run the archiving product, you do not need to change any configuration information before you use the notifications.

1. On the server where you run archiving processes, choose Setup > System Configuration > System Settings and click the E-mail tab.

2. Set the site.email.smtp_url property to the URL of your e-mail server.3. Set the site.email.sender property to an appropriately formatted e-mail

address for your site. 4. Click Save. Now, when you set up an archiving process, select the appropriate check boxes for sending the notifications and type the addresses to which you want the notifications sent.


33

The START notification is sent when a process starts for the first time and when it resumes after being paused.

The END notification is sent when a process completes or when it is paused. Use the system log

The information contained in the system logs provides the best opportunity for diagnosing problems that might occur during archiving processes. For example, if an archiving process pauses automatically due to an error, the log is the best place to find information about the error. Archiving log information for a process is saved to log files on the server from which the process is run. The log files are stored in instance name\logs within the systems installation directory. It is recommended that you make the following adjustments to the log settings to ensure that the appropriate archiving information is included: 1. Change the Log Level.

The archiving product writes most entries to the log in INFO mode. Therefore, to ensure that your log files contain enough information for diagnosing any potential problems, you must change the archiving log level from ERROR to INFO before running any archiving processes. a. Choose Setup > System Configuration > System Settings and click the

Log File tab on the server that will run the archiving process. b. Set the site.log.loglevel property to INFO. c. Click Save. d. Restart the system server to make the change take effect, before you run

an archiving process. With a log level setting of INFO, more information about all processes is written to the log than is necessary for normal operation. Therefore, you might want to switch this setting before and after an archiving process.

Note: If you are using a non-production server to run archiving processes (as recommended), you can leave the log level set to INFO, since the server is writing very little of anything other than archiving information to the log.


34

Using a non-production server that is always set to INFO mode is the only way to guarantee that a scheduled archiving process always writes sufficient information to the log files.

2. Adjust the Log File Settings.Partially due to the fact that it writes entries in INFO mode, the archiving product generates many log entries when it runs a processenough to fill up several log files very quickly. Therefore, you should increase the maximum allowable size for each log file, the number of log files allowed, or both. Doing this helps ensure that your logs will contain enough historical information to diagnose any problem that might affect an archiving process.

Note: It is recommended that you copy and save your logs to a different location after each archiving process so that they can be retrieved later, if necessary.


35

To change the default log file settings:a. Choose Setup > System Configuration > System Settings and click the

Log File tab on the server that will run the archiving process.b. Set the site.log.file.rollover.maxsize property as desired. c. This property controls the maximum size of each log file. It should be set

to at least 500KB. d. Set the site.log.file.rollover.maxlogs property as desired.

This property controls the number of new log files that will be created before the earliest log files are overwritten. Before running an archiving process, set this to a number large enough to guarantee that your logs will not be overwritten during the process; for example, 100. Then, when the process is finished, you can change it back.

e. Click Save. f. Restart the system server, to make the changes take effect, before you run

an archiving process.

Note: You might want to save some of the log files to a different location after an archiving process completes. In this way, you can keep track of the large amount of log information that is created.

Maintenance

This section contains tips and reminders that serve to keep archiving processes performing at a high level and suite users productive once you start using the archiving product.

Database maintenance

Along with your production database, non-production databases containing archived data need to be maintained in order to ensure the best possible performance of the archiving product. This section describes the kind of maintenance to perform after running an archiving process.


36

Source and Target Database Maintenance

Archiving processes add and remove large amounts of data from the source and target databases. Keeping up-to-date database statistics for the RDBMS optimizer enhances the performance of these processes. After running an archiving process, perform the following on the source and target databases, according to the instructions in the Database Administrators Guide for the suite: For SQL Server databases: Run update statistics from within the Query

Analyzer tool. For Oracle databases: Run update statistics from within SQL*Plus or some

other Oracle interface. It is recommended that you run a Reconcile on the source and target databases after each copy. Use Database Manager to run a Reconcile.

Note: When you run a Reconcile on a non-production database to which data has been copied, the output in the log might show that there are missing foreign keys within the database. This is most often because rows that contain references to each other are not copied together, because of the date associated with one or both of the rows. Missing foreign keys of this nature do not affect the accuracy of data contained on the database and are included in the system log as INFO level entries that contain the text Could not create FK on database.

If the system log contains WARNING or ERROR level entries that contain the text Error while trying to create FK on database then a more serious omission exists, perhaps due to errors on the source database. Contact a service representative for assistance.

Target Database Maintenance

The target database of a Copy or Archive process should be cleaned up after the process is complete. This means performing regular database maintenance such as backing up the database, defragmenting the database, and running the automated database utilities supplied with the system installation (SQL Server only). For more information about database maintenance, refer to the Database Administrators Guide for the suite.


37

Source Database Maintenance

After an Archive or Purge process, where data is deleted from the source database, you may want to run a database shrink, to reclaim the disk space from the purged data. Defragmenting the database after data is deleted helps to improve the performance of the database. It is recommended that you back up your production database after each archiving process, so that audit trail information is protected.

Updating the Locator Editor

The Locator Editor and the Record Locator components of the archiving product work together to make it possible for users to quickly identify and access data that has been archived. The Record Locator is the user interface for accessing databases that contain archived data, while the Locator Editor is the tool used to maintain the Record Locator (information stored in the Locator Editor is used to populate the Record Locator). Administering the archiving product involves keeping the Locator Editor up-to-date. Any time you successfully copy information to a non-production database, the name of the database and the range of dates it contains are automatically added to the Locator Editor workspace on the production database. You need to add the URL for the system server that points to that database and save the Locator Editor entry in order to populate the Record Locator. When you specify a URL, specify the entire URL, including the double forward slash (//); otherwise, the URL you enter in the Locator Editor (for use in the Record Locator) is interpreted as a relative URL from the system server.

Note: You cannot access a system database unless there is a system server pointing to it.

If you ever permanently change the server that points to a particular database, you need to update the URL entry for that database in the Locator Editor or the link in the Record Locator will not work. The Locator Editor also provides a text box where you can enter a description of the database. This additional information appears in the Record Locator, along with the server URL and the range of dates for the database, and may help users


38

find the archived information they are looking for more quickly. As a database grows or changes in any way, you can edit this description.

Note: If you do not have a server pointing to a database listed in the Locator Editor, you could indicate this to the user in the text of the description, perhaps by instructing them to reconfigure another server to access the database.

Some text is required in the URL text box in the Locator Editor, however, in order for the entry to appear in the Record Locator. Enter placeholder text if a URL does not exist, but you still want the entry to appear.

Turn off background processes on the archive system

Record Manager does not turn off all processes. When using an archive database to retrieve historical information, some processes should be manually turned off. The recommended background processes to turn off are: All Workforce Timekeeper users connected to the database Process Manager Engine Process Manager Cluster Manager Background Processor Audit Settings in System Settings All scheduled events in Event Manager including shift builder.

Note: If you are running Record Manager on a non-production (target) server, turn off individual events, rather than Event Manager itself, otherwise no Record Manager jobs can be scheduled on the target server.

Device ManagerNote: This list is not complete and is subject to change as new features and new background processes are added to the Workforce Central suite.


39

Storing data offline

Depending on your resources, you might decide to keep part of your archived data offline. Storing data offline is not an archiving function, and you cannot copy data directly to offline media using the archiving product. However, the archiving product allows you to copy data, in a selected range of dates, from one database to another, where it can be backed up to a smaller file. The archiving product allows you to combine smaller, segmented databases into one database, if it becomes necessary for example, if you need to run a report that spans dates contained in two or more smaller databases. For information about combining databases, refer to Adding non-production databases on page 39

Note: If you upgrade your system servers after you back up a database, and then you restore the database, you need to upgrade the database to the same version as the server in order to access the data that the database contains.

Adding non-production databases

You can add new non-production databases at any time; for example, if you want to copy selected information from one non-production database to another, for backup purposes or to create a new test database for rules. The number of non-production databases that you use, and when and if you add more databases after initial installation, depends on your archive strategy. Adding a non-production database to the archiving environment involves creating an empty database, building the database, and adding information about the database to the production database. Refer to the products Installation Guide for information about adding a non-production database.

Troubleshooting

By default, an archiving process pauses and posts a message to the archiving Monitor tab when an error occurs. If you set up an END notification for the process, you will also receive an e-mail notification stating that the process has paused due to error.


40

The first thing to do when a process pauses in error is check that the database and network connections are working. Try restarting the server to reconnect. Often, the condition that causes a process to pause is temporary, such as temporary database or network unavailability. After you have checked your connections and restarted the server, attempt to resume the process by clicking Resume. In many cases, the process will be able to complete successfully. If the process pauses in error a second time, the error is most likely not temporary, and you are left with three options: Fix the problem and then resume the process. Call a service representative for assistance. Cancel the process (use Cancel only when no other solution exists) and start

over with a restored database.

Note: The most common errors encountered while running the archiving product are caused by incorrect configuration of the Record Retention - Affected Databases tab entries. These errors result in database offline messages or empty start and end date drop-down boxes on the Copy and Archive screens. A job may also start, but end up paused due to error because of an incorrect name entry in the Affected Databases tab. Follow the instructions for entering database information closely.

The information contained in the system logs provides the best opportunity for diagnosing problems that might occur during archiving processes. If you are going to attempt to fix the problem yourself, the logs are the first place that you should look. Archiving log information for a particular process is saved in the log files on the server from which the process is run. The logs are stored in the instance name\logs directory within the system installation directory.

Note: Archiving log data is only written to the logs when the log level setting for the server running the archiving product is set to INFO. For more information, see Use the system log on page 33.

If you Cancel a process, you will need to restore one or more databases. Do not attempt to re-run the Copy, Purge, or Archive process after Canceling a process, without first restoring the appropriate database. Starting a process on the same


41

database without restoring only causes more problems. The appropriate database to restore is determined by the type of process that was canceled. The next section deals with the Cancel option in more detail.

Canceling a process

The Cancel process control permanently stops an archiving process and leaves the database in an undetermined state where your only option is to restore the database to an earlier backup. Whenever possible, use Pause instead of Cancel to stop a process. You might be able to fix whatever problem you are having and resume the process to completion, and you can always cancel a paused process later if you realize a Cancel is your only option.

Caution: Use Cancel only as a last resort. After a Cancel, you must restore your database from an earlier backup.

Note: An exception to the rule of restoring a database after canceling a process is when a process is paused due to error because the jdbcconnector.#.name field is entered incorrectly. For more information about this, refer to Correcting the name of a database in the Record Retention - Affected Databases tab on page 42.

Typically, both a Cancel and a Pause take effect within ten minutes. In order to run, pause, resume, or cancel an archiving process, each of the databases involved in the process must be online.

Note: User access to Cancel is controlled by the archiving products Cancel access control point. Because the Cancel control has the ability to leave a database in an undetermined state, you may want to limit user access to it.

If you do need to perform a Cancel, you will need to restore the affected database from a backup. If you cancel a Copy process, restore the target database. If you cancel a Purge process, restore the source database.


42

Note: If you are running an archiving process, look on the Monitor tab before you cancel the process to see the current state of the process. The current state of the process is named in parentheses following Archive.

If you cancel during the Copy state of the Archive process, restore the target database.

If you cancel during the Purge state of the Archive process, restore the source database.

Correcting the name of a database in the Record Retention - Affected Databases tab

One reason that an archiving process pauses in error is that the name entry in the Record Retention - Affected Databases tab is entered incorrectly. If this is the case, the archiving product returns an error early in the processing of tables, when it attempts to load data from a table on the source database to a table on the target database. When you get this kind of error, check the database name in the Affected Databases tab and remember that, for Oracle databases, the appropriate suffix for the database must be included in the name. If the name appears to be correct, this type of error may indicate that there is an incorrect entry in your tnsnames.ora file. If an incorrect database name entry is the problem, cancel the job, enter the correct name in the Affected Databases tab, restart the system server, and start a new process. You do not need to restore any of your databases, because the process that you canceled did not get far enough into the work to permanently affect any data (as long as you rerun the process before attempting to view information on the target database). If you attempt to change the name of the database and then resume the process (rather than canceling the process, changing the name, and then starting a new process), the process immediately shows a status of completed with error. This is because the archiving product does not support changing the name field in the Affected Databases tab after a process has started, even if it is paused. If you get a status of completed with error for this reason, stop and restart the system server, and then rerun the process.


43

Unable to log on to the server after an error

In rare cases, running an archiving process from a server that points to the target database can cause problems when you try to log on to the target database. This happens only if an error occurs during the copy of the table that contains the logon information. If you cannot log on to the target database, the process has paused due to error during the copy of this table and, therefore, has not completed copying the information necessary to allow you to log on. Point the server to another database or log on to the server in off-line mode in order to resume or cancel the process, depending on the problem.

Restarting a process after server downtime

If the server from which you are using the archiving product fails or is shut down or restarted while archiving process is running, the process stops running and must be restarted manually once the server is restarted. To restart the archiving process, after restarting the failed server:1. Access the archiving workspace on the system server from which the process

was originally started.2. Go to the Monitor tab.

The process should be shown as Paused by User.3. Click Resume. The process is now running and should resume where it left off before the server or servers in question became unavailable.

Cannot purge source database

If you cannot run a purge operation on a source database, an error message appears that indicates you need to run one or more retroactive copies between the source database and one or more target databases. Retroactive Copy copies the data that the archiving product has not previously supported. After you successfully run the Retroactive Copy, you can purge the source database.


44

Recordmanager references

When you see references to database Recordmanager in the archiving messages and logs, it is referring to your production database.

Chapter 3

Accessing Archived Data

Authorized users can access archived data through a system server that points to an archive database. Once connected to an archive database, users can access the same information and functionality that they can on the production database. This chapter describes how to grant the appropriate archive access to users and how to locate and access archived data. This chapter contains the following sections: Granting access to archived data on page 46 Locating and accessing archived data on page 48

Chapter 3 Accessing Archived Data

46

Granting access to archived data

By default, the archiving product prevents all user accounts, except system accounts and those that use system logon profiles, from accessing an archive database after a Copy or Archive process. You can grant access to users, as follows: In the production databaseUsers with archive access granted in the

production database will be able to access all copies of the archived database. You cannot specify specific archive databases; that is, the user can access all or none.

In the archive databaseUsers with archive access granted in the archive database will be able to access only that archive. The user will have the same access to the archive database as was granted on the production database. Therefore, some accounts may be able to edit the archived data (for example, People Profiles, Rules, and so on). However, when you archive the database again, the users archive access is overwritten and you must grant access to the archive database again.

Note: The archiving product can only prevent access to archive databases when the server that you use to access the archived database uses Kronos authentication. If the server uses Lightweight Directory Access Protocol (LDAP) or NT authentication, the lock-out applied by the archiving product is ignored, and you are not required to grant users access to archived data.

To grant access to a specific archive database to a user:1. Log on to the archive database using the ArchiveIS, ArchivePayroll, or

SuperUser user account. 2. Open the employees People Record on the archive database and click the

Person tab.3. Click User Information from the list at the left of the screen. 4. Select the Access to archive database check box. If you are reluctant to give out access to system accounts, and are concerned that employees who use their own, unlocked accounts, may inadvertently edit archived data, consider setting up new user accounts specifically for accessing archived

Granting access to archived data

47

data. These new user accounts can use access profiles that you create with limited viewing and editing abilities. Use the access profiles to prevent users from viewing all employees and from editing inappropriate data.For example, you could create an access profile that grants an appropriate level of access for a department or group of people within your company, and then assign that profile to a new user account named after the department. All the employees in the department would use this generic account, instead of their own, to access archived data.

Note: Be sure to grant access to archive databases to the new user account.


48

Locating and accessing archived data

Authorized users can access archived data on a non-production database through a system server that points to that database. You can view data on an archive database in the same way that you view data on a production database. Do not attempt to edit data on an archive database. Use the Record Locator to determine the server that contains the archived data that you want to view. To access the Record Locator, click the Record Locator link in the system navigation bar. The Record Locator displays an entry for each database that has been copied to. Each entry shows the range of dates that are included on the database, and a link to the server that points to the database, if one has been supplied. There may also be a description of the database and the data it contains. If you are looking for information from the past, the first step is to check the Record Locator for the dates that have been copied from the production database. If a non-production database contains the dates that you need, you should access the information on the non-production database, even if the same range of dates is contained on the production database. This will ensure that there is enough data to calculate accruals information correctly.

Note: Due to the nature of Projected Accrual Balances, they do not calculate accurately on an archive database.

Locating and accessing archived data

49

Viewing data during an archiving process

You can view archived data before, during, and after the Copy and Archive processes. The location of viewable data depends on the state of the process; sometimes you view the source database, and other times you view the target database. The following table shows which database to view before, during, and after a Copy and Archive process:

* Before you can view data on the target database, you must stop and restart the system server that points to that database.

Note: A Purge process erases data from the source database. Therefore, the data being purged cannot be viewed on the source database during or after a Purge. However, you can most likely view this information on a different database since, with the exception of Purge with Purge Override, the Purge process can only purge data that has already been copied to another database.

Switching databases

The database to which a system server points is typically configured during the installation of the server. However, you can change the database that is referenced by an server by altering some of the key values in the System Settings component of the suite. If you have not installed an server for every database, at sometime you will need to reconfigure one of your existing servers in order to access archived data. For more information, see the product installation guide.

Process Before During After

Copy Source Source Source or Target*Archive Source Source during Copy

Target* during PurgeTarget*


50

Combining databases

You can use the archiving product to merge two or more databases into one database. You might want to combine multiple databases to: Access data more easily from a single database. Run a report across multiple years of data that are stored on separate

databases. Combining databases works similarly to archiving data. Instead of moving data from your production database to a non-production database, you move data from one non-production database to another. The same general rules as for archiving data apply. Refer to Appendix A, Rules and GuidelinesQuick Reference, on page 65.

Note: Only databases containing data that originated on the same database can be combined.

Setup Data Manager is a separately installed utility of Record Manager that allows you to copy the system setup data from a source to a target database. For example, you can use it to update your production database with rules that were originally configured or tested on a non-production system.

Note: Before you copy setup data from one database to another, make sure that you fully understand the implications of copying that data. You should back up your target database before you copy setup data from one database to another. After the copy, there is no way to back out of or undo the changes.

This chapter contains the following sections: Using Setup Data Manager on page 52 How it works on page 53 Setup Data Manager user interface on page 54 Transferring setup data on page 55

52

Using Setup Data Manager

Setup Data Manager uses the system programming interfaces (APIs) to copy setup data from one database to another. For example, use Setup Data Manager to copy setup data that has been created and tested on a test or development database, to a production database. To copy setup data, select the system servers that point to a source and a target database, and then choose the setup data items. Each item represents a different piece of setup data. The items are uniquely identified by name. If an item is copied to a target database that already contains an item of the same name, the existing item is updated. If an item of the same name does not exist on the target database, the item is added. Items that exist on the target database, but not in the source, are not affected by Setup Data Manager (that is, they are not deleted from the target database).

How it works

53

How it works

Setup Data Manager uses the systems XML APIs to copy setup data. This capability lets you copy a great range of setup data available in the suite and choose specific categories of setup data to copy. Setup Data Manager adds or updates setup data items based on the name of the item: If the item name already exists on the target database, then the item is

updated. If the item name does not exist on the target database, then the item is added. An item is never deleted from the target database, regardless of whether it

exists or has been deleted from the source database. Setup Data Manager must be able to access the system XML schema files for the source and the target database. The schema file determines what data can be copied and how it is copied. The changes made to setup data on the target server during the setup data transfer are written to the servers audit trail, just as if they were entered manually on the target system.

54

Setup Data Manager user interface

The menu bar for the Setup Data Manager contains the following options:

Menu Options

File Open an existing transfer, run an existing transfer, or create a new transfer.Edit Cut, copy, or paste information in the user interface.Report Access the Last Run Log report. The Last Run Log gives a summary report

of the last transfer that was run, including source information, target information, and copied data categories/items.

Admin Update Schema DefinitionRetrieve the latest XML schema document from a new or upgraded system database. Be sure to keep the schema documents for the database versions you use up to date. Change Workforce Central API TimeoutEdit the length of time that the application waits for a response during an API request.Change PasswordDisplay the Reset Admin Password Dialog Box, which allows you to enter a different password for access. LicenseShow information about the Setup Data Manager license or configure the license.

Window Basic window options: cascade, tile horizontally or vertically, and close all.Help Displays the Setup Data Manager online Help and product version and

licensing information.

Transferring setup data

55


To copy setup data, you must run a transfer definition file using Setup Data Manager. The transfer file defines the source and target databases for the copy, and the specific data to be copied.

Note: The XML Schema file must be downloaded before creating or opening a new transfer definition file (.tdf) or the database version will not be updated.

To configure a setup data transfer: 1. Open Setup Data Manager. You must enter a password.

To change the password, select Admin > Change Password from the Setup Data Manager menu and enter a new password.

2. To create a new transfer definition file, select File > New. To open an existing transfer definition file, select File > Open.

3. Click General and enter a description for the transfer. 4. Click Source and specify:

Enter connection parameters for the source server Choose the system API Export to transfer the data from system server. Choose XML Document to transfer the data from an XML file. If you are using an XML Document, make sure it is an XML document that had previously been created with Setup Data Manager.

System server URL (for system API Export only) Enter the URL for the system server that points to the database from which to copy setup data. For information about constructing the URL, refer to Entering the system server URL on page 62.

Output path/Filename (for XML Document only) The location and name of the XML file from which to transfer data.

Other settings appear when you transfer data from the system server using API Export. Login name Enter the login name for the system server.

56

Password Enter the password for the system server. System database version Select the version of the source database.

Click Find db version to query the server to determine the database version. The reported version is automatically entered as the database version.

Database name Contains the name of the database retrieved when you click Find db version.

Database server Contains the name of the database server retrieved when you click Find db version.

Submit using SSL Select this to extract data from the system using Secure Sockets Layer.

5. Click Target and specify: Enter connection parameters for the target server Choose Import to

transfer the data directly to a system server. Choose XML Document to write the data to an XML file.

System server URL (for system Import only) Enter the URL for the system server that points to the database to which you want to copy setup data. For information about constructing the URL, refer to Entering the system server URL on page 62.

Output path/Filename (for XML Document only) The location and name of the XML file to be created. Click the ellipsis button to browse to the directory and file. If you want to create a new directory for the file, you must use Windows Explorer. Existing files are overwritten if the same name is reused.

Other settings appear when you transfer data directly to the server using Import. Login name Enter the login name for the system server. Password Enter the password for the system server. System database version Select the version of the target database.

Click the Find db version button to query the server to determine the


57

database version. The reported version is automatically entered as the database version.

Database name Contains the name of the database retrieved when you click Find db version.

Database server Contains the name of the database server retrieved when you click Find db version.

Submit using SSL Select this to copy data to the system using Secure Sockets Layer.

Submit transfer errors to the Transaction Assistant Select this to send errors that occur during the copy to the Transaction Assistant on the target server.

Note: Errors are always included in the XML Error Log.

Batch Name Enter the name of the batch. 6. Click Transfer and choose the setup data categories and items that you want

to copy. Some setup data items depend on others in order to work properly. Be sure that you copy all dependent setup data items. If your source is an XML file, all setup data categories in that file are copied; you cannot specify which items to copy. If your source is the system and your target is an XML file, only the selected setup data categories and items are included in the XML file. For more information, refer to Configuring Transfer information on page 58.

7. Click Start Transfer.

Note: The settings in the General, Source, and Target tabs can be saved as part of the transfer file (select File > Save).

If you transfer new or reconfigured rules to your production database, reassign the necessary people to the appropriate rules, after the transfer. For instructions about how to do this, refer to the systems online Help.Errors that occur as part of the transfer are reported in the XML Error Log and are sent to the Transaction Assistant on the target server, if you have enabled it. To access the XML Error Log, go to the Log Files folder within the SDM installation

58

directory. Errors are contained in the transferFileName_server_Trans.xml file. For more information about the Transaction Assistant, refer to the systems online help.

Note: If you lose contact with the database or server at any time during the transfer, you can run the transfer again. Anything that was copied during the first transfer will be updated; anything that was not copied will be added.

If your connection to the source or target server continually times out during the Copy, you may need to extend the application timeout value. Select Admin >Change Workforce Central API Timeout and change the value.

In particular, to allow sufficient time for InTouch Soft Key settings data to transfer, navigate to Admin > Change Workforce Central API Timeout and set the value to 600 seconds or greater..

Configuring Transfer information

Use Transfer to select the setup data items that you want to copy. Setup data items are sorted according to data categories, such as Wage Profiles, Setup, similar to the organization of the data in Setup on the system navigation bar. Some data categories are a sub-category of these larger categories. For example, Work Rules are a sub-category of Pay Policies within the general category of Setup. A setup data item is a specific Work Rule or Pay Rule.

Note: Only the setup data items that you selected are copied. There is no effect on setup data items that you choose not to copy.

To select a setup data item to copy: 1. In the Setup Data Categories pane, click the name of the category that

includes the item you want to copy. Select the check box to the left of the category name to copy the entire category. You can also choose to Select All data categories.


59

Each time you select a different setup data category, the list of items in the Setup Data Items - Source pane is updated to reflect the items stored in the source database.

Note: Select Cache setup data items list to cache the list of items within the selected category. This way, you dont have to wait for the list to be updated each time you select the category. If you select this option and a setup data item is added while you are using Setup Data Manager, the new item is not automatically updated in the list. Deselect the check box and select the category name again to update the list.

2. In Setup Data Items - Source, select the check box for each setup data item that you want to copy. You can also choose to Select All items. Only setup data items that you are allowed to transfer are shown. When possible the name of each setup data item is the same as the name that appears in the system user interface. When a name does not match an entry in the system user interface, it appears in square brackets. Some items are read-only, and, therefore, cannot be edited or transferred.

Note: To view a list of s

WFC70_RecordMgrUserGuide

Documents

Transcript of WFC70_RecordMgrUserGuide