runIntegration

Führt einen Data Integration-Job aus, um Daten in einen Oracle Enterprise Performance Management Cloud-Geschäftsprozess zu importieren oder aus einem Geschäftsprozess in ein externes System zu exportieren.

Dieser Befehl ersetzt den veralteten Befehl runDataRule. Oracle empfiehlt, dass Sie diesen Befehl anstelle des Befehls runDataRule verwenden.

Gilt für

Planning, Planning Modules, FreeForm, Financial Consolidation and Close, Tax Reporting, Account Reconciliation, Profitability and Cost Management, Enterprise Profitability and Cost Management, Sales Planning und Strategische Personalplanung.

Erforderliche Rollen

Serviceadministrator, Poweruser

Verwendung

epmautomate runIntegration JOB_NAME importMode=Append|Replace|"Map and Validate"|"No Import"|Direct exportMode=Merge|Replace|Accumulate|Subtract|"No Export"|Check periodName={PERIOD_NAME} [inputFileName=FILE_NAME] [PARAMETERS]

Bei Integrationen im Standardmodus müssen Sie die Werte für importMode, exportMode und periodName angeben.
Bei Integrationen im Schnellmodus müssen Sie den Wert für exportMode angeben.
Bei Parameternamen und -werten wird zwischen Groß- und Kleinschreibung unterschieden.

In diesem Befehl gilt Folgendes:

JOB_NAME ist der Name eines Integrationsjobs, der in Data Integration definiert ist.
importMode bestimmt, wie die Daten in Data Integration importiert werden. Zulässige Importmodi:
- Append, um die vorhandenen POV-Daten in Data Integration hinzuzufügen.
- Replace, um die POV-Daten zu löschen und durch die Daten aus der Datei zu ersetzen.
- Map and Validate, um den Datenimport zu überspringen, die Daten aber mit aktualisierten Zuordnungen und Logikaccounts neu zu verarbeiten.
- No Import, um den Datenimport in die Staging-Tabelle von Data Integration zu überspringen.
exportMode bestimmt, wie die Daten in der Zielumgebung geladen werden. Bei Integrationen im Schnellmodus können Sie Check oder No Export nicht als Wert des Parameters exportMode verwenden. Folgende Exportmoduswerte sind zulässig:
- Merge, um die vorhandenen Daten zu aktualisieren und neue Daten hinzuzufügen.
- Replace, um die vorhandenen Daten im POV zu löschen und neue Daten zu laden. Im Standardmodus werden die Daten für Scenario-, Version-, Year-, Period- und Entity-Dimensionen gelöscht. Im Schnellmodus werden Daten für Year-, Period- und Entity-Dimensionen gelöscht. Sie können benutzerdefinierte zu löschende Regionen für beide Modi definieren.
- Accumulate, um die Daten den vorhandenen Daten hinzuzufügen. Anwendbar für Planning, Planning Modules, Financial Consolidation and Close, Tax Reporting, Profitability and Cost Management und Enterprise Profitability and Cost Management.
- Subtract, um die Daten vom vorhandenen Saldo abzuziehen. Dieser Wert gilt für Profitability and Cost Management und Enterprise Profitability and Cost Management.
  Für Integrationen im Schnellmodus gilt:
  - Sie dürfen nicht Check oder No Export als Parameterwert verwenden.
  - Für Planning, Planning Modules und Financial Consolidation and Close sind nur die Werte Replace, Merge und Accumulate gültig.
- No Export, um den Datenexport zu überspringen. Verwenden Sie diesen Modus, um Daten zur Prüfung in die Staging-Tabelle zu laden, bevor sie in der Zielanwendung geladen werden.
- Check, um nur eine Datenvalidierungsprüfung auszuführen.
  
  Bei Oracle Fusion Cloud als Ziel werden nur diese Exportmodi unterstützt:
  - MERGE, um die Daten in der Staging-Tabelle von Data Integration mit den vorhandenen Daten zusammenzuführen.
  - NONE, um den Datenexport aus Data Integration in die Anwendung zu überspringen.
periodName ist der Name der Perioden oder Periodenbereiche (jeweils in geschweifte Klammern eingeschlossen), für die Daten importiert oder exportiert werden sollen. Zulässige Namenskonventionen für Perioden:
- Geben Sie für Ladevorgänge einzelner Perioden den Periodennamen in geschweiften Klammern an. Beispiel: {Jan-21}
- Geben Sie für Ladevorgänge mit mehreren Perioden die Namen der Start- und Endperiode in geschweiften Klammern an. Beispiel: {Jan-21}{Mar-21} (zum Laden der Daten für alle Perioden von Januar 21 bis März 21)
- Für Planning, Planning Modules, Financial Consolidation and Close, FreeForm und Tax Reporting: Sie können den Namen und das Jahr der Periode des Geschäftsprozesses im Format {Jan#FY21}{Mar#FY21} angeben, um Daten für alle Perioden von Januar 21 bis März 21 zu laden.
  Der Periodenname muss in geschweiften Klammern angegeben werden.
  - Einzelne Periode: Bezieht sich auf den Periodennamen der Komponente Datenmanagement für eine einzelne in der Periodenzuordnung definierte Periode.
  - Mehrfachperiode: Bezieht sich auf einen Ladevorgang für mehrere Perioden. Der Parameter wird im Format {Month-Year}{Month-Year} angegeben. Beispiel: {Jan-20}{Mar-20} gibt einen Ladevorgang für mehrere Perioden von Januar 20 bis März 20 an.
  - Planning-Periodenname: Bezieht sich auf einen Planning-Periodennamen im Format {Month#Year}. Beispiel: {Jan#FY20}{Mar#FY20}. Bei dieser Konvention müssen Sie keine Data Integration-Periodennamen angeben. Stattdessen geben Sie die Elementnamen für die Year- und Scenario-Dimensionen an.
    Dieser Parameter wird in den Geschäftsprozessen Planning, Tax Reporting und Financial Consolidation and Close unterstützt. Er funktioniert sowohl für Ihre Serviceanwendungen als auch für Cloud-Deployments, die von On-Premise-Datenquellen abgeleitet wurden.
    
    Diese Konvention eignet sich bei Auslösung durch ein EPM Cloud-Groovy-Skript, indem die Namen von Jahres- und Periodenelementen erfasst werden. Die Periodenzuordnung der Anwendung oder die globale Periodenzuordnung muss mit dem Jahr und Monat in den Zielwerten der Periodenzuordnung vorhanden sein.
  - Substitutionsvariable: Dabei handelt es sich um eine Erweiterung des oben genannten Planning-Periodennamensformats. Dabei kann eine Substitutionsvariable anstelle der tatsächlichen Jahres- und Monatselementnamen im Format {Month#&CurYr}{&FcstMonth#&CurYr} angegeben werden. Beispiel: {Jan#&CurYr}{&FcstMonth#&CurYr}.
    Tatsächliche Elementnamen können auch mit Substitutionsvariablen kombiniert werden.
    
    Dieses Format wird in den Geschäftsprozessen Planning, Tax Reporting und Financial Consolidation and Close unterstützt.
    
    Die Periodenzuordnung der Anwendung oder die globale Periodenzuordnung muss in Data Integration der Umgebung vorhanden sein, in der dieser Befehl ausgeführt wird. Dabei müssen Jahres- und Monatswerte in den Zielwerten der Periodenzuordnung verfügbar sein. In diesem Fall beziehen sich Jahr und Monat auf den aktuellen Wert der Substitutionsvariablen bei der Ausführung.
  - Globaler POV: Führt den Dataload für die globale POV-Periode aus. Verwenden Sie das Format {GLOBAL_POV}.
  Note:
  Wenn Sie einen anderen Parameter für die Periodenbenennung als die hier beschriebenen verwenden, wird die Fehlermeldung Ungültige Eingabe - HTTP 400 angezeigt.
  
  Kopieren Sie den Abschnitt periodName aus der REST-API-Dokumentation. Dort werden die verschiedenen Formate wie globaler POV, Substitutionsvariable usw. erläutert.
- {GLOBAL_POV} zum Ausführen des Dataloads für die im globalen POV im System oder in den Anwendungseinstellungen in Data Integration definierte Periode.
  
  Note:
  Das Format zur Periodenbenennung {Month#Year} wird für Planning, Planning Modules, Financial Consolidation and Close und Tax Reporting unterstützt. Mit dieser Konvention können Sie Elementnamen für die Year- und Scenario-Dimensionen anstelle der Data Integration-Periodennamen angeben. Dieser Ansatz ist nützlich, wenn der Befehl aus einem Groovy-Skript ausgelöst wird, indem die Namen von Jahres- und Periodenelementen erfasst werden.
  Die Namenskonvention mit Substitutionsvariablen {Jan#&CurYr}{&FcstMonth#&CurYr} ist eine Erweiterung der oben genannten Namenskonvention für Perioden. Sie können Substitutionsvariablen anstelle der Jahres- und Monatselementnamen angeben, wenn Sie diesen Befehl für Planning, Planning Modules, Financial Consolidation and Close und Tax Reporting ausführen. Elementnamen können auch mit Substitutionsvariablen kombiniert werden.
  Die oben genannten Namenskonventionen mit Periodennamen und Substitutionsvariablen funktionieren nur, wenn bereits Anwendungsperiodenzuordnungen oder globale Periodenzuordnungen mit Jahr und Monat in den Zielwerten in Data Integration vorhanden sind.
inputFileName gibt bei dateibasierten Dataloads den Namen der Datei (in der Inbox verfügbar) an, aus der Daten importiert werden sollen. Wenn Sie den Verzeichnisnamen in der Integrationsdefinition angeben, übergeben Sie nur den Dateinamen. Wenn Sie keinen Verzeichnisnamen in der Integrationsdefinition angeben, verwenden Sie das Format inbox/DIR_NAME/FILE_NAME. Beispiel: inbox/GLBALANCES.txt oder inbox/EBSGL/GLBALANCES.txt. Wenn die Datei in den Standardspeicherort der Umgebung hochgeladen wurde, verwenden Sie die Konvention #epminbox/FILE_NAME, z.B. #epminbox/GLBALANCES.txt, um die Eingabedatendatei anzugeben.
Dieser Parameter ist nur bei nativen dateibasierten Dataloads anwendbar. Wenn Sie diesen Parameterwert für dateibasierte Dataloads nicht angeben, importiert dieser Befehl Daten aus der in der Integrationsdefinition angegebenen Datei. Wenn Sie diesen Parameterwert für Dataloads angeben, die nicht dateibasiert sind, ignoriert dieser Befehl ihn.
PARAMETERS identifiziert optional Laufzeitparameter im Format PARAMETER_NAME="PARAMETER" . Parameter beinhalten sowohl Quellfilter als auch Zieloptionen.

Note:
Der einzige Parameter, den Sie derzeit für Zielanwendungen vom Typ "Dimension" (Metadaten) verwenden können, ist "Refresh Database"=Yes|No.

Beispiele

Import für einzelne Periode:
epmAutomate runIntegration VisionDataLoad importMode=Replace exportMode=Merge period="{Mar-15}"
Import mit mehreren Perioden:
epmAutomate runIntegration VisionDataLoad importMode=Replace exportMode=Merge period="{Mar-15} {Jun-15}"
Inkrementelle dateibasierte Datenintegration:
epmAutomate runIntegration IncrementalFileLoad importMode=Replace exportMode=Merge period="{Jan-20}{Mar-20}" inputFileName=File1.txt