5 データの準備
この章の内容は次のとおりです。
ソース・データの準備: 考慮する点
このトピックでは、Oracle HCM Cloudにロードするデータを準備し、正常にロードできるようにするいくつかの方法について説明します。
ソース・データのレビューおよびクレンジング
Oracle HCM Cloudにアップロードするビジネス・オブジェクトと、そのソース・システムを識別します。このソース・データをレビューして、それが正確で最新の状態であることを確認します。抽出を試行する前に、すべての問題を修正します。次に例を示します。
-
すべての就業者に対してマネージャが識別され、かつその情報が正確であることを確認します。
-
ジョブおよびポジションについて、正しいジョブ・コードとタイトルがソース・システムに存在することを確認します。
-
就業者の履歴について、履歴データの正確性を確認します。すべての履歴データをアップロードする必要があるか、採用、昇格・昇進、退職などの主要なイベントのみをアップロードするかを把握します。
この方法でソース・データを準備すると、Oracle HCM Cloudにデータをアップロードするときに問題が発生する可能性が最小化されます。また、新しい環境に不正確なデータをロードする可能性も低くなります。
ソース・システムからのデータの抽出
ソースとターゲットの属性を比較することによって、ソース・データとOracle HCM Cloudビジネス・オブジェクト・モデルとのマッピングを定義する必要があります。Oracle HCM Cloudのビジネス・オブジェクトの構造をレビューするには、次のようにします。
-
「データ交換」作業領域の「データ・ロードの開始」ページを開きます。
-
「検索結果」表の「ビジネス・オブジェクト」列でビジネス・オブジェクトの名前を選択します。
選択したオブジェクトの「ビジネス・オブジェクト詳細」ページが開きます。次の内容が表示されます。
-
オブジェクトのコンポーネント階層
-
選択したコンポーネントに関する、有効日かどうか、その属性、フレックスフィールド・データをロードできるかどうかなどの、いくつかの一般的な詳細
-
変換ロジックを定義して、抽出ルーチンを構築する必要もあります。Oracle E-Business SuiteのPL/SQLやOracle PeopleSoftのSQRなど、ソース・システムのネイティブ・ツールを使用できます。または、Oracle Data IntegratorやPowerCenter Informaticaなどの抽出、変換およびロード・ツールを使用できます。
アップロード前のソース・データの検証
HCMデータ・ローダーによって、データ・ロードのインポート・フェーズとロード・フェーズの両方でデータが検証されます。My Oracle Supportから取得できるデータ・ファイル・バリデータ・ツールを使用すると、データのロードを試行する前に、データの書式設定のほとんどの検証を実行できます。生成された.datファイルをテストするには、ソース環境でこのユーティリティを実行します。このユーティリティにより、検証エラーのリストがHTML形式で生成されます。ロードする前に、.datファイルのエラーを修正できます。
データ・ファイル・バリデータ・ツールは、My Oracle Supportドキュメント『HCMデータ・ローダー用のデータ・ファイル・バリデータ・ツール』(文書ID 2022617.1)からダウンロードできます。
HCMデータ・ローダーのデータに関する一般的な考慮事項: 説明
このトピックでは、データ準備のいくつかの一般的な側面について説明します。データが正常にアップロードされるようにするには、次のルールに従います。
現行値の保持
Oracle HCM Cloudの既存のデータを更新するときには、次のことを指定します。
-
更新しているレコードの一意の識別子
-
変更された属性
除外した属性では、現行値が保持されます。パフォーマンス上の理由により、変更されていない属性を含めないことをお薦めします。
Nullの属性値
属性値を明示的にnullに設定するには、属性値として#NULLトークンを指定する必要があります。単に属性を空白のままにすることはできません。
参照により検証される属性
Oracle HCM Cloudで参照タイプとして定義された非フレックスフィールド属性については、参照コードまたはその意味を指定できます。たとえば、次の表に示す参照コードまたは参照の意味を使用して、個人の性別を指定できます。
参照コード | 参照の意味 |
---|---|
M |
男性 |
F |
女性 |
参照の意味は翻訳可能であるため、参照コードを使用することをお薦めします。参照の意味の言語は、データをアップロードするユーザーの言語と一致する必要があります。
参照タイプとして定義されたフレックスフィールド属性には、様々なルールが適用されます。
数値
数値では、小数点セパレータのみがサポートされます。通貨記号、科学表記法または3桁区切りを含めないでください。既存の数値をnullに設定するには、属性値として#NULLトークンを指定します。
日付属性および時間属性
次の表に、日付と時間の値に対して予期される形式を示します。
日付または時間 | 形式 |
---|---|
日付 |
YYYY/MM/DD |
時間 |
YYYY/MM/DD HH24:MI:SS |
例: 2016/11/05 14:20:00
既存の日付または時間の値をnullに設定するには、属性値として#NULLトークンを指定します。
イメージ、添付ファイルおよび大きい文字列のロード: 説明
HCMデータ・ローダーを使用して、キャラクタ・ラージ・オブジェクト(CLOB)とバイナリ・ラージ・オブジェクト(BLOB)の両方をロードできます。ただし、これらのオブジェクトのデータの指定方法は、これらの属性に固有です。データは、データ(.dat)ファイルに直接指定するのではなく、個別のファイルとして渡します。このファイルの名前は、データ・ファイルに、関連する属性の値として指定します。
次の例は、ドキュメントの添付ファイル・コンポーネントのデータ・ファイルを示しています。File属性によって、各MERGE行のテキスト添付ファイルが参照されます。
METADATA|DocumentAttachment|DocumentType|File|PersonNumber|...
MERGE|DocumentAttachment|Drivers License|file01.txt|23901|...
MERGE|DocumentAttachment|Drivers License|file02.txt|64235|...
これらのデータ型のデータは非常に大きくなる可能性があるため、このアプローチを使用します。また、添付ファイルを使用しないでデータを直接ロードする場合は、改行文字が必要になることがあるため、ビジネス・オブジェクト・データ・ファイルに含める内容が複雑になります。
CLOBファイルおよびBLOBファイルの指定方法
CLOB属性にデータをロードするには、個別のファイルとしてデータを渡します。このファイルは、ビジネス・オブジェクト・データ・ファイルと同じ.zipファイルのClobFilesフォルダに配置します。同様に、BLOB属性にデータをロードしたり添付ファイルをアップロードするには、データまたは添付するファイルをBlobFilesフォルダに置きます。ラージ・オブジェクトまたは添付ファイルのロードに使用される属性のデータ型によって、使用するフォルダが決まります。
ビジネス・オブジェクト・ドキュメントには、すべての属性のデータ型が指定されています。たとえば、ドキュメントの添付ファイル・コンポーネントのFile属性は、BLOBデータ型になります。したがって、次の図に示すように、BlobFilesフォルダに参照ファイルを配置します。

ClobFilesフォルダとBlobFilesフォルダにあるファイルの名前には、UTF-8シングルバイト文字を使用できます。たとえば、ファイル名には、aからz、AからZ、0から9、アンダースコア(_)、ハイフン(-)およびカッコ( )を使用できます。通常、CLOBデータはテキスト(.txt)ファイルで渡しますが、ほとんどのファイル名拡張子がサポートされています。
ソース・キー値の指定: 考慮する点
ソース・キーは、SourceSystemOwnerとSourceSystemIdの2つの属性で構成されます。マージするレコードの識別にソース・キーを使用する場合は、統合有効外部オブジェクトの識別にもソース・キーを使用できます。たとえば、ソース・キーを使用して子コンポーネントの親レコードを識別できます。ローカル・レコードにソース・キーを使用していない場合は、外部オブジェクト参照にもソース・キーを使用できません。
このトピックでは、ローカル・レコードと外部オブジェクト参照の両方にソース・キーを指定する方法について説明します。また、デフォルトのソース・キーがどのように構成されているかについても説明します。
ソース・システム所有者の値の定義
SourceSystemOwner属性は、レコードで指定されたすべてのソース・キーに共通です。このため、ソース・キーを使用して識別するすべての外部オブジェクトは、そのSourceSystemOwner値が、マージするレコードのものと同じである必要があります。ソース・キーを使用する前にHRC_SOURCE_SYSTEM_OWNER参照タイプを更新して、SourceSystemOwner値を定義する必要があります。
ローカル・レコードに対するソース・キーの指定
ソース・キーを使用して一意にローカル・レコードを識別するには、SourceSystemIdとSourceSystemOwnerの両方のソース・キー属性に値を指定します。次の例は、ソース・キーを使用したジョブ・オブジェクトの識別方法を示しています。
METADATA|Job|SourceSystemId|SourceSystemOwner|JobCode|JobName|SetCode|EffectiveStartDate|EffectiveEndDate
MERGE|Job|12349|EBS-UK|SE|Software Engineer|COMMON|2010/01/01|4712/12/31
外部オブジェクト参照に対するソース・キーの指定
外部オブジェクト参照にソース・キーを使用するには、外部オブジェクトのサロゲートID属性にヒント(SourceSystemId)を追加します。次の例は、ソース・キーを使用した、アサイメント・レコードのジョブ・オブジェクトの識別方法を示しています。JobIdがジョブ・オブジェクトのサロゲートID属性であり、METADATA行でこれにヒント(SourceSystemId)を追加します。HCMデータ・ローダーを使用して、指定したソース・キーでジョブ・オブジェクトを作成している必要があります。
METADATA|Assignment|SourceSystemId|SourceSystemOwner|JobId(SourceSystemId)|EffectiveStartDate|EffectiveEndDate
MERGE|Assignment|234234|EBS-UK|12349|2013/01/01|4712/12/31
デフォルトのソース・キー
HCMデータ・ローダーを使用してレコードを作成するとき、ソース・キーを指定しないと、デフォルトのソース・キーが生成されます。デフォルトのSourceSystemOwner値はFUSIONで、SourceSystemIdはサロゲートIDです。ソース・キーを使用して、デフォルトのソース・キーが指定されたレコードを識別できます。ソース・キー・オブジェクトを使用して、デフォルトのソース・キーを含む既存のソース・キーを更新することもできます。ただし、ソース・キー情報を抽出するプロセスはありません。
ソース・キーの更新: 説明
HCMデータ・ローダーを使用してデータをロードするときに、ソース・キーを指定できます。ソース・キーは、通常はレガシー環境から生成される値で、これによってその環境内のレコードが一意に識別されます。オブジェクトを保守するときと別のオブジェクトからオブジェクトを参照するときの両方で、ソース・キーを使用してそのオブジェクトを参照できます。ソース・キーを指定しないと、デフォルトのソース・キーが生成されます。統合有効オブジェクトに対しては、デフォルトのソース・キーとローカルで定義されたソース・キーの両方を更新できます。このトピックでは、ソース・キーを更新する方法について説明します。
ソース・キーへの更新のロード
いずれかのレコードに関連付けられたソース・キーを更新するには、SourceKey.datファイルをロードします。更新するレコードへの参照と新しいソース・キー値の両方をファイルに指定します。
このSourceKey.datファイルの例では、既存のソース・キーで識別された個人住所のソース・キーを更新します。更新するレコードのタイプの識別には、BusinessObject属性とComponent属性が使用されます。両方の属性値に対して、該当するファイル弁別子を指定します。
METADATA|SourceKey|BusinessObject|Component|OldSourceSystemId|OldSourceSystemOwner|NewSourceSystemId|NewSourceSystemOwner
MERGE|SourceKey|Worker|PersonAddress|2342|FUSION|1422-HOME|VISION
ユーザー・キー値の指定: 考慮する点
ユーザー・キーは、ロードするビジネス・オブジェクト・コンポーネントに固有です。統合されたビジネス・オブジェクト・ドキュメントに、すべてのビジネス・オブジェクト・コンポーネントと外部オブジェクト参照の使用可能なユーザー・キー属性が示されています。
レコードを作成するときに、ユーザー・キーが必要になります。これらは、異なるキー・タイプを指定してレコードを一意に識別する場合を除いて、更新するときにも必要になります。このトピックでは、ユーザー・キーを使用してローカル・レコードを識別し、外部オブジェクトを参照する方法について説明します。また、ユーザー・キー値の変更がキーとしての有用性に及ぼす影響についても説明します。
ローカル・レコードに対するユーザー・キーの指定
ユーザー・キーは、複数の属性で構成できます。ソース・キーなどの別のキー・タイプを使用してレコードを識別していない場合は、これらをすべて指定する必要があります。次の例は、ジョブ・オブジェクトを、JobCode属性とSetCode属性で構成されるそのユーザー・キーによって識別する方法を示しています。
METADATA|Job|JobCode|JobName|SetCode|EffectiveStartDate|EffectiveEndDate
MERGE|Job|SE|Software Engineer|COMMON|2010/01/01|4712/12/31
外部オブジェクト参照に対するユーザー・キーの指定
次の例では、アサイメント・オブジェクトがそのソース・キーによって一意に識別されます。ただし、関連するジョブ・オブジェクトへの外部オブジェクト参照には、ユーザー・キーが使用されます。
METADATA|Assignment|SourceSystemId|SourceSystemOwner|JobCode|SetCode|EffectiveStartDate|EffectiveEndDate
MERGE|Assignment|234234|EBS-UK|SE|COMMON|2013/01/01|4712/12/31
変更されたユーザー・キー値の管理
ユーザー・キーの値の中には、固定的でないものがあります。たとえば、組織または事業所の名前を変更できます。ユーザー・キーは変更される可能性があるため、履歴参照にこれらを使用することは困難です。ユーザー・キーが変更されたビジネス・オブジェクト・コンポーネントの有効日履歴をロードする場合は、ソース・キーも指定する必要があります。このアプローチにより、HCMデータ・ローダーで関連する有効日レコードを適切に識別して、ロードするオブジェクトを形成できるようになります。
Oracle FusionサロゲートIDの指定: 例
新しいレコードをデータベースに保存すると、そのレコードにOracle FusionサロゲートIDが自動的に割り当てられます。サロゲートIDは、ロードするビジネス・オブジェクト・コンポーネントに固有です。統合されたビジネス・オブジェクト・ドキュメントに、すべてのビジネス・オブジェクト・コンポーネントと外部オブジェクト参照のサロゲートID属性が示されています。このトピックでは、サロゲートIDを使用してローカル・レコードを識別し、外部オブジェクト参照を実現する方法について説明します。
ローカル・レコードに対するサロゲートIDの指定
次の例は、サロゲートIDを使用したジョブ・コンポーネントの識別方法を示しています。このコンポーネントでは、JobId属性がそのサロゲートIDです。
METADATA|Job|JobId|JobName|EffectiveStartDate|EffectiveEndDate
MERGE|Job|13413|Software Engineer - Java|2013/01/01|4712/12/31
外部オブジェクト参照に対するサロゲートIDの指定
次の例は、ソース・キーを使用して一意に識別されたアサイメント・コンポーネントを示しています。このレコードには、そのサロゲートIDであるJobIdで識別される、関連するジョブ・オブジェクトへの外部オブジェクト参照が含まれます。
METADATA|Assignment|SourceSystemId|SourceSystemOwner|JobId|EffectiveStartDate|EffectiveEndDate
MERGE|Assignment|234234|EBS-UK|13413|2013/01/01|4712/12/31
Oracle Fusion GUIDの指定: 例
Oracle Fusion GUID (グローバル一意識別子)は、レコードがデータベースに保存されると自動的にレコードに割り当てられる、16進数値です。このトピックでは、GUIDを使用してローカル・レコードを識別し、外部オブジェクト参照を実現する方法を示しています。
ローカル・レコードに対するGUIDの指定
GUID値を指定してマージするレコードまたは削除するレコードを識別する場合は、ビジネス・オブジェクト・コンポーネントに関係なく、属性名GUIDを使用します。次の例は、GUID値を指定したジョブ・コンポーネントの識別方法を示しています。
METADATA|Job|GUID|JobName|EffectiveStartDate|EffectiveEndDate
MERGE|Job|2342UJFHI2323|Software Engineer - Java|2013/01/01|4712/12/31
外部オブジェクト参照に対するGUIDの指定
外部オブジェクト参照にGUIDを使用するには、参照先のオブジェクトのサロゲートID属性にヒント(GUID)を追加します。次の例は、ソース・キーを使用して識別されたアサイメント・コンポーネントを示しています。このレコードには、そのGUIDで識別される、関連するジョブ・オブジェクトへの外部オブジェクト参照が含まれます。JobIdがジョブ・オブジェクトのサロゲートID属性です。
METADATA|Assignment|SourceSystemId|SourceSystemOwner|JobId(GUID)|EffectiveStartDate|EffectiveEndDate
MERGE|Assignment|234234|EBS-UK|2342UJHFI2323|2013/01/01|4712/12/31
外部オブジェクトが統合有効オブジェクトである場合にのみ、外部オブジェクトに対してGUIDを使用できます。統合されたビジネス・オブジェクト・ドキュメントに、統合有効オブジェクトである外部オブジェクトが示されています。
予約文字の管理: 説明
HCMデータ・ローダーのデータ・ファイルのコンテキストには、いくつかの文字が予約されています。つまり、それらにはデフォルトで特定の意味があり、それらをデータとして明示的に識別する場合を除いて、属性値に含めることはできません。このトピックでは、アップロードするデータに予約文字を使用する方法について説明します。また、デフォルトの予約文字を上書きする方法についても説明します。
属性値での予約文字の使用方法
デフォルトでは、次の文字が予約されています。
-
デリミタ(縦棒|)
-
改行文字(n)
-
エスケープ(バックスラッシュ\)
改行文字(n)と縦棒(|)を属性値に含めるには、エスケープ文字(バックスラッシュ\)をその直前に指定します。次に例を示します。
METADATA|Address|AddressLine1
MERGE|Address|The Stables\|Main Allan
このエントリにより、住所行1の属性値に次のように縦棒を表示できます。
The Stables|Main Allan
値に改行文字を含めるには、\nを指定します。次に例を示します。
METADATA|Address|AddressLine1
MERGE|Address|The Stables\nMain Allan
このエントリでは、住所行1の値は次のようになります。
The Stables
Main Allan
予約文字の上書き
SETファイル行命令を使用して、ファイルの予約文字を上書きできます。SETファイル行命令はファイルのMETADATA行の前に置く必要があります。予約文字を上書きするSETコマンドの形式は、次のとおりです。
SET FILE_ESCAPE <new_value>
SET FILE_DELIMITER <new_value>
SET FILE_NEW_LINE <new_value>
最大で10文字の新しい値を指定できます。たとえば、次のSETコマンドを使用して、改行文字をnewlineに、デリミタをカンマ(,)に設定できます。
SET FILE_DELIMITER ,
SET FILE_NEW_LINE newline
この場合、METADATA行とMERGE行は次のようになります。
METADATA,Address,AddressLine1
MERGE,Address,TheSteading\newlineKier Allan
翻訳されたオブジェクトのロードおよび維持: 説明
複数の言語が有効である環境では、HCMデータ・ローダーを使用して、翻訳されたオブジェクトをアップロードできます。「ファイル文字セット」構成パラメータで、Javaでサポートされる文字セットを指定して、データ・ファイルの文字セットを指定します。デフォルトの文字セットはUTF-8です。
翻訳されたオブジェクトのロード
翻訳されたオブジェクトのロードは、2つのステージで構成されるプロセスです。
-
ベース言語バージョンをロードして、オブジェクトを作成します。このステージでは、すべての有効な言語に対して翻訳レコードが作成されますが、これらには翻訳可能な値のベース言語バージョンが保持されます。たとえば、米国英語がベース言語である場合は、翻訳レコードには翻訳可能な値の米国英語バージョンが保持されます。
-
ベース言語オブジェクトに対する訂正として、翻訳された値をロードします。このステップを実行するには、翻訳用に提供されているデータ・ファイル・テンプレートを使用します。翻訳データ・ファイル・テンプレートは、翻訳可能な値を含むビジネス・オブジェクト・コンポーネントごとに1つ提供されます。
たとえば、米国英語がベース言語である環境で営業マネージャ・ジョブを作成する場合があります。フランス語、ドイツ語およびスペイン語も有効である場合は、次の表に示すようにオブジェクトが作成されます。
言語 | ソース言語 | ジョブ名 |
---|---|---|
米国英語 |
米国英語 |
営業マネージャ |
フランス語 |
米国英語 |
営業マネージャ |
ドイツ語 |
米国英語 |
営業マネージャ |
スペイン語 |
米国英語 |
営業マネージャ |
このオブジェクトが存在するようになると、単一の翻訳データ・ファイル(JobTranslation.dat)をロードして、ジョブ名のフランス語バージョン、ドイツ語バージョンおよびスペイン語バージョンを訂正できます。または、必要に応じて、各言語の翻訳ファイルをロードできます。翻訳ファイルは、元のオブジェクトと同じ.zipファイルで提供することも、個別に提供することもできます。ただし、ベース言語オブジェクトが存在するようになる前は、これらを提供できません。
翻訳されたデータの更新
オブジェクトが有効日ではない場合は、該当する翻訳ファイルのみをアップロードして、既存の翻訳されたデータを更新できます。
次の場合は、ベース言語オブジェクトを更新する必要もあります。
-
オブジェクトが有効日である。
-
現在、オブジェクトに、新しい翻訳値と同じ有効開始日を持つ有効日レコードが存在しない。
この要件は、ベース言語と翻訳オブジェクトで有効日が同じである状態を維持するために存在します。
翻訳オブジェクトは、単独では削除できません。翻訳オブジェクトは、関連オブジェクトを削除したときに自動的に削除されます。たとえば、ジョブ・ファミリ・オブジェクトを削除すると、関連するすべての翻訳オブジェクトが自動的に削除されます。
翻訳ファイル弁別子
翻訳ファイルには一意のファイル弁別子が存在し、関連するファイルで識別されます。たとえば、ファイルJobTranslation.datのファイル弁別子は、JobTranslationです。
次の例は、関連するJobTranslation.datファイルが続くJob.datファイルを示しています。
METADATA|Job|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|JobCode|Name|ActiveStatus
MERGE|Job|EBS-UK|JB2ACC44|2010/01/01|2014/04/04|ACADM|Accounts Administrator|A
MERGE|Job|EBS-UK|JB2ACC44|2014/04/05|4712/12/31|ACADM|Accounts Clerk|A
METADATA|JobTranslation|SourceSystemOwner|SourceSystemId|EffectiveStartDate|EffectiveEndDate|Language|Name
MERGE|JobTranslation|EBS-UK|JB2ACC44|2010/01/01|2014/04/04|ES|Administrador de Cuentas
MERGE|JobTranslation|EBS-UK|JB2ACC44|2014/04/05|4712/12/31|ES|Cuentas Clerk
データ・ファイルへのソース・システム参照の組込み: 説明
ファイル内の各データ行に、ソース・システム参照を含めることができます。これにより、ソース・システムからのデータベース表名、列名および属性値を記録できます。ロードが失敗するオブジェクトについては、「オブジェクト・エラー」ページでこれらの値を確認できます。そのため、データ・ソースを簡単に識別できます。ソース・システム参照はオプションです。このトピックでは、名前と値で構成されるソース・システム参照の構築方法について説明します。
ソース・システム名
関連するMETADATA行に、ソース・システムのデータベース表名と列名を指定します。ソース・システムのデータベース表名を指定するには、METADATA行に次のエントリを追加します。
SourceRefTableName=<table name>
SourceRef001からSourceRef010までのタグを使用して、同じMETADATA行に最大10個のソース・システムの列名を指定できます。次に例を示します。
METADATA|Job|SourceRefTableName=PER_JOBS|SourceRef001=JOB_ID|SourceRef002=EFFECTIVE_START_DATE|SourceRef003=EFFECTIVE_END_DATE
ソース・システム参照は、METADATA行の命令とファイル弁別子の後の、任意の場所に配置できます。
ソース・システム値
各データ行にソース・システム値を指定し、このとき、必ず、METADATA行に指定した順序で配置します。データ行では、ソース・システムのデータベース表名を空白のままにする必要があります。この値は、METADATA定義にのみ出現します。次に例を示します。
METADATA|Job|SourceRefTableName=PER_JOBS|SourceRef001=JOB_ID|SourceRef002=EFFECTIVE_START_DATE|SourceRef003=EFFECTIVE_END_DATE
MERGE|Job||135|2010/01/01|4712/12/31
MERGE|Job||136|2010/01/01|4712/12/31
データの削除: 説明
HCMデータ・ローダーを使用してロードされたかどうかに関係なく、HCMデータ・ローダーを使用して多くのオブジェクトを削除できます。このトピックでは、オブジェクトとそのコンポーネントを削除する方法について説明し、制限を示しています。
削除できるものとできないもの
次のものを削除できます。
-
就業者を除く、ほとんどの完全なビジネス・オブジェクト。
-
ほとんどの個別のビジネス・オブジェクト・コンポーネント。
-
就業者オブジェクトの一部の子コンポーネント。たとえば、就業者オブジェクトの個人Eメール・コンポーネントを削除できます。
親オブジェクトを削除すると、その子オブジェクトとすべての翻訳オブジェクトも削除されます。たとえば、等級オブジェクトとその子ビジネス・オブジェクト・コンポーネントを削除するには、Grade弁別子のDELETE命令を作成します。等級レート値の子コンポーネントのみを削除するには、GradeRateValue弁別子のDELETE命令を作成します。
次のものは削除できません。
-
個別の有効日レコード
-
個別の翻訳オブジェクト
-
就業者オブジェクト
ビジネス・オブジェクト・コンポーネントを削除できるかどうかに関する情報は、「データ交換」作業領域の「データ・ロードの開始」ページでビジネス・オブジェクトの詳細を参照してください。
DELETE命令
オブジェクトを削除するには、関連するデータ・ファイルにDELETE命令を含めます。たとえば、JobFamily.datファイルに次の行を含めて、ジョブ・ファミリ・オブジェクトを削除できます。
METADATA|JobFamily|EffectiveStartDate|EffectiveEndDate|JobFamilyName
DELETE|JobFamily|2012/10/01|4712/12/31|Sales01
次のルールが適用されます。
-
翻訳データ・ファイルにはDELETE命令を含めることはできません。
-
MERGE命令が指定されたオブジェクトに対しては、同じファイルにDELETE命令を指定しないでください。HCMデータ・ローダーでは、最初にどの命令を処理するかは判断されません。
有効日オブジェクトの削除
ユーザー・キーで識別される有効日オブジェクトを削除するには、有効開始日と有効終了日の両方を指定する必要があります。他のいずれかのキー・タイプを使用してオブジェクトが識別される場合、有効開始日と有効終了日はオプションになります。