Verwenden der persistenten Eingabedatei
Wenn Sie pmrep mit einigen Aufgaben ausführen, verwenden Sie eine persistente Eingabedatei zum Angeben der Repository-Objekte, die Sie verarbeiten möchten. Die persistente Eingabedatei repräsentiert bereits im Repository vorhandene Objekte. Sie können eine persistente Eingabedatei manuell oder mithilfe von pmrep erstellen.
Verwenden Sie eine persistente Eingabedatei mit den folgenden pmrep-Befehlen:
- •AddToDeploymentGroup. Fügt Objekte einer Bereitstellungsgruppe hinzu.
- •ApplyLabel. Beschriftet Objekte.
- •ExecuteQuery. Führt eine Abfrage aus, um eine persistente Eingabedatei zu erstellen. Verwenden Sie die Datei für andere pmrep-Befehle.
- •ListObjectDependencies. Listet Abhängigkeitsobjekte auf. Dieser Befehl kann eine persistente Eingabedatei für die Verarbeitung verwenden und er kann eine erstellen.
- •MassUpdate. Aktualisiert die Sitzungseigenschaften für eine Reihe von Sitzungen.
- •ObjectExport. Exportiert Objekte in eine XML-Datei.
- •Validate. Validiert Objekte. Dieser Befehl kann eine persistente Eingabedatei für die Verarbeitung verwenden und er kann eine erstellen.
Die persistente Eingabedatei verwendet das folgende Format:
encoded ID, foldername, object_name, object_type, object_subtype, version_number, reusable|non-reusable
Erstellen einer persistenten Eingabedatei mit pmrep
Sie können eine persistente Eingabedatei unter Verwendung der pmrep-Befehle ExecuteQuery, Validate oder ListObjectDependencies erstellen. Mithilfe dieser Befehle werden Dateien erstellt, die eine Liste von Objekten mit verschlüsselten IDs und einem CRC-Wert (Cyclic Redundancy Check, zyklische Redundanzprüfung) enthalten. Weiterhin ist eine verschlüsselte Repository-GID enthalten. Mit dieser ID wird das Repository angegeben, aus dem der Datensatz stammt.
Die pmrep-Befehle, die eine persistente Eingabedatei verwenden, rufen die Objektinformationen aus den verschlüsselten IDs ab. Die verschlüsselten IDs ermöglichen pmrep die schnelle Verarbeitung der Eingabedatei.
Beim Erstellen einer persistenten Eingabedatei mit pmrep wird diese im pmrep-Installationsverzeichnis gespeichert. Sie können einen anderen Pfad angeben.
Der folgende Text zeigt ein Beispiel für eine persistente Eingabedatei:
2072670638:57bfc2ff-df64-40fc-9cd4-a15cb489bab8:3538944199885:138608640183285:1376256153425:131072168215:65536142655:0288235:088154:65536122855,EXPORT,M_ITEMS,mapping,none,2
1995857227:57bfc2ff-df64-40fc-9cd4-a15cb489bab8:3538944135065:13867417666804:1376256233835:19660880104:65536271545:0319425:017154:6553644164,EXPORT,M_ITEMS_2,mapping,none,3
1828891977:57bfc2ff-df64-40fc-9cd4-a15cb489bab8:3538944279765:138739712184505:137625613474:65536221345:65536133675:091734:09053:65536156675,EXPORT,M_NIELSEN,mapping,none,1
3267622055:57bfc2ff-df64-40fc-9cd4-a15cb489bab8:353894462954:138805248300075:1376256151365:6553675414:65536174015:0273455:0241435:65536261685,EXPORT,M_OS1,mapping,none,1
Beispiel
Sie können den Befehl ExecuteQuery zum Erstellen einer persistenten Eingabedatei für Objekte verwenden, die in einem anderen pmrep-Befehl verarbeitet werden. Sie möchten beispielsweise alle logisch gelöschten Objekte aus dem Repository exportieren. Sie können eine Abfrage mit der Bezeichnung "find_deleted_objects" erstellen. Wenn Sie die Abfrage wie hier angezeigt mit pmrep ausführen, werden alle gelöschten Objekte im Repository gefunden und die Ergebnisse in eine persistente Eingabedatei geschrieben:
ExecuteQuery -q find_deleted_objects -t private -u deletes_workfile
Sie können "deletes_workfile" dann als persistente Eingabedatei für ObjectExport verwenden:
ObjectExport -i deletes_workfile -u exported_del_file
ObjectExport exportiert alle referenzierten Objekte in eine XML-Datei mit der Bezeichnung "exported_del_file".
Manuelles Erstellen einer persistenten Eingabedatei
Wenn Sie pmrep-Befehle für eine Gruppe von Objekten ausführen möchten, die über Befehle wie ExecuteQuery nicht ermittelt werden können, besteht die Möglichkeit zur manuellen Erstellung einer Eingabedatei.
Verwenden Sie die folgenden Regeln und Richtlinien, wenn Sie ein persistente Eingabedatei erstellen:
- •Geben Sie "none" für die verschlüsselte ID ein. Die pmrep-Befehle erhalten die Objektinformationen aus den anderen Argumenten in den Datensätzen.
- •Geben Sie für Quellobjekte den Objektnamen wie folgt ein: <DBD_name>.<source_name>.
- •Geben Sie für Objekte, wie z. B. Mappings, die nicht über sub_type verfügen, "none" als object_subtype ein oder nehmen Sie keine Eingabe vor. Weitere Informationen zu gültigen Umwandlungen und Aufgabentypen finden Sie unter Listing Object Types.
- •Geben Sie bei versionierten Repositories die Versionsnummer des gewünschten Objekts ein. Alternativ können Sie auch "AKTUELL" eingeben, um die aktuelle Version des Objekts zu verwenden.
- •Lassen Sie bei unversionierten Repositories das Argument version_number leer.
- •Ignorieren Sie das Argument bei Objekttypen, wie z. B. Targets, die weder wiederverwendbar noch nicht wiederverwendbar sein können.
- •Nicht wiederverwendbare Objekte können nicht aufgenommen werden. Sie können das wiederverwendbare übergeordnete Objekt des nicht wiederverwendbaren Objekts angeben.
Sie möchten beispielsweise die Objektabhängigkeiten für eine nicht wiederverwendbare Filtertransformation auflisten. Sie können das Mapping, das als übergeordnetes Objekt der Transformation fungiert, angeben:
none,CAPO,m_seqgen_map,mapping,none,1,reusable
Das Mapping m_seqgen_map ist das wiederverwendbare übergeordnete Objekt der Filtertransformation. Der Befehl wird erfolgreich ausgeführt, wenn Sie das wiederverwendbare übergeordnete Objekt angeben.
Beispiel
Das folgende Beispiel zeigt eine manuell erstellte persistente Eingabedatei:
none,EXPORT,CustTgt,target,none,2
none,EXPORT,S_Orders,session,,2,reusable
none,EXPORT,EXP_CalcTot,transformation,expression,LATEST,reusable
Im ersten Datensatz handelt es sich bei CustTgt um eine Target-Definition. Targets haben keinen Untertyp, d. h., Sie geben "none" für das Argument object_subtype ein. Ein Target kann weder wiederverwendbar noch nicht wiederverwendbar sein, daher kann das Wiederverwendbarkeitsargument wegfallen. Beachten Sie, dass der Datensatz sechs statt sieben Argumente aufweist.
Im zweiten Datensatz handelt es sich bei S_Orders um eine Sitzung. Sitzungen haben keinen Untertyp, d. h. Sie lassen das Argument leer.
Der dritte Datensatz soll die aktuelle Version der Transformation aufweisen, d. h., Sie geben "LATEST" für das Argument version_number ein.