[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[[["\u003cp\u003eOracle EBS data integration utilizes Incorta to ingest data into a BigQuery CDC dataset, processing it via a hosted or private instance.\u003c/p\u003e\n"],["\u003cp\u003eThe Cortex Framework transforms and materializes the Oracle EBS CDC data into reporting assets, orchestrating BigQuery jobs using Cloud Composer.\u003c/p\u003e\n"],["\u003cp\u003eDeployment configuration parameters, such as item category sets, currency conversion types, and languages, are defined in the \u003ccode\u003econfig.json\u003c/code\u003e file.\u003c/p\u003e\n"],["\u003cp\u003eThe Oracle EBS Order to Cash Logical Data Model includes base fact views, dimension tables, header tables, and aggregate tables, with a structure available in an entity relationship diagram.\u003c/p\u003e\n"],["\u003cp\u003eAggregate tables within the data model provide daily measures and currency-converted amounts, which requires users to derive non-additive measures to avoid overcounting when aggregating.\u003c/p\u003e\n"]]],[],null,["# Integration with Oracle EBS\n===========================\n\nThe Oracle EBS (E-Business Suite) integration supports Order to Cash data models with data\ningestion using [Incorta](https://www.incorta.com/). Incorta uses a hosted\nor private instance to ingest the data from Oracle into a BigQuery\nCDC dataset and handles the CDC processing. From there,\nCortex Framework transforms and materializes\nthe CDC data into reporting assets using Cloud Composer to orchestrate\nBigQuery jobs.\n\nThe following diagram describes how Oracle EBS data is\navailable through the Oracle EBS operational workload:\n\n**Figure 1**. Cortex Framework-Oracle EBS-Incorta Integration Overview . **Note:** For accessing configuration files, analytical views and models for operational data sources, see the [Cortex Framework Data Foundation repository](https://github.com/GoogleCloudPlatform/cortex-data-foundation).\n\nDeployment configuration\n------------------------\n\nThe following table shares the parameters for configuring the Oracle EBS workload:\nThe [`config.json`](https://github.com/GoogleCloudPlatform/cortex-data-foundation/blob/main/config/config.json) file configures the settings required to transfer data from\nany data source, including Oracle EBS. This file contains the following parameters for\nOracle EBS:\n\n| **Note:** The default values for `itemCategorySetIDs`, `currencyConversionType`, `currencyConversionTargets`, and `languages` work with the test data deployment. However for a production deployment, these values depend on your Oracle EBS instance. For help with determining appropriate values,contact your Oracle administrator.\n\nData Ingestion\n--------------\n\nReach out to an Incorta representative and refer to\n[Oracle EBS for Google Cortex Setup Guide](https://docs.incorta.com/latest/blueprints-oracle-ebs-google-cortex-setup-guide)\nfor details on ingesting data from Oracle to BigQuery.\n\n### Recommended configurations\n\nAlthough Incorta supports scheduling data ingestion jobs at various intervals,\nfor optimal performance and data freshness, we recommend scheduling Incorta\ndata ingestion jobs to run daily. If your use case requires handling\ndeleted data, make sure to enable those by following the instructions in the\nIncorta documentation, [Handling source deletes](https://docs.incortaops.com/latest/blueprints-oracle-ebs-google-cortex#handling-source-deletes).\n\nReporting configurations\n------------------------\n\nThis section outlines the necessary reporting configurations for your environment.\n\n### Cloud Composer Airflow connection\n\nCreate a BigQuery Airflow connection named\n`oracleebs_reporting_bq` that will be used by the BigQuery\noperator to perform reporting transforms. See more details in the\n[Manage Airflow connections documentation](/composer/docs/how-to/managing/connections).\n\n### Materializer settings\n\nFind materialization settings in\n[`src/OracleEBS/config/reporting_settings.yaml`](https://github.com/GoogleCloudPlatform/cortex-data-foundation/blob/main/src/OracleEBS/config/reporting_settings.yaml).\nBy default the [dimension](#dimension_tables),\n[header](#header_tables), and\n[aggregate](#aggregate_tables) tables\nare materialized daily. The reporting layer tables are also date partitioned.\nPartitions and clustering can be customized if needed. For more information,\nsee [Cluster Settings](/cortex/docs/deployment-step-five#cluster_settings)\nand [Table Partition](/cortex/docs/deployment-step-five#table_partition).\n\nData Model\n----------\n\nThis section describes the Oracle EBS Order to Cash Logical Data Model. Each\nsubsection explains the following Oracle EBS Entity Relationship Diagram (ERD).\n\n[](/static/cortex/docs/images/erd_oracle_ebs.png)\n**Figure 2**. Oracle EBS: Entity Relationship Diagram.\n\n### Base fact views\n\nThese are the blue objects in the ERD and are views on CDC tables with\nno transforms other than some column name aliases.\n\n### Dimension tables\n\nThese are the purple objects in the ERD and contain the relevant dimensional\nattributes used by the reporting tables. By default, these dimensions are\nfiltered down based on the [deployment configuration](#deployment_configuration)\nparameter values where applicable. This integration also uses the Cortex K9\nGregorian calendar dimension for date attributes, which is deployed by default.\n\n### Header tables\n\nThese are the green objects in the ERD and contain the joined facts and dimensions that\ndescribe business entities like orders and invoices at the header level. The header tables\nare partitioned by a primary event date corresponding to each entity, for example\n`ORDERED_DATE` or `INVOICE_DATE`.\n\n#### Nested and repeated Lines\n\nThe `SalesOrders` and `SalesInvoices` tables contain\n[nested repeated fields](/bigquery/docs/best-practices-performance-nested)\nnamed `LINES`. These fields group the various order lines and invoice lines\nunder their associated headers. To query these nested fields, use the `UNNEST`\noperator to [flatten the elements into rows](/bigquery/docs/arrays) as shown in\nthe provided sample scripts (`src/OracleEBS/src/reporting/ddls/samples/`).\n| **Caution:** Be careful when unnesting repeated fields to avoid double counting the top level measures.\n\n#### Nested and repeated attributes\n\nSome tables contain additional nested repeated fields such as `ITEM_CATEGORIES`\nor `ITEM_DESCRIPTIONS` where multiple values of the same attribute may apply to\nthe entity. If unnesting these repeated attributes, be sure to filter down to a\nsingle attribute value to avoid over counting measures.\n\n#### Applied Receivables\n\n`SalesAppliedReceivables` is a unique table in that the entities can reference\neither invoices on their own, or an invoice with a cash receipt. As such there\nare nested (but not repeated) `INVOICE` and `CASH_RECEIPT` fields, where the\n`CASH_RECEIPT` field is only populated when `APPLICATION_TYPE = 'CASH'`.\n\n### Aggregate tables\n\nThese are the red objects in the ERD and aggregate from the header tables up to\ndaily measures. Each of these tables are also partitioned by a primary event\ndate. The aggregate tables only contain additive measures (for example,\ncounts, sums) and don't include measures like averages and ratios. This means\nthat users must derive the non-additive measures to ensure they can be\nderived appropriately when aggregating up to a higher grain, such as monthly.\nSee sample scripts like `src/OracleEBS/src/reporting/ddls/samples/SalesOrderAggMetrics.sql`.\n\n#### Currency conversion Amounts\n\nEach aggregate table uses the `CurrencyRateMD` dimension to create a nested\nrepeated field of `AMOUNTS` containing currency measures converted into each\nof the target currencies specified in the [deployment configuration](#deployment_configuration).\nWhen using these measures, make sure to filter to a single target currency or\ngroup on target currencies for reporting to avoid over counting. This can also\nbe seen in the sample scripts like `src/OracleEBS/src/reporting/ddls/samples/SalesOrderAggMetrics.sql`.\n\n#### Nested line attributes and measures\n\nThe `SalesOrdersDailyAgg` table contains a nested repeated field named\n`LINES` to differentiate between line level attributes and measures (for example,\n`ITEM_CATEGORY_NAME` and `AMOUNTS`) versus header level attributes and measures\n(for example, `BILL_TO_CUSTOMER_NAME` and `NUM_ORDERS`). Take care to\nquery these grains separately to avoid over counting.\n\nAlthough invoices also have a notion of headers versus lines, the table\n`SalesInvoicesDailyAgg` only contains measures at the line level, so it doesn't\nfollow the same structure as `SalesOrdersDailyAgg`.\n\nWhat's next?\n------------\n\n- For more information about other data sources and workloads, see [Data sources and workloads](/cortex/docs/data-sources-and-workloads).\n- For more information about the steps for deployment in production environments, see [Cortex Framework Data Foundation deployment prerequisites](/cortex/docs/deployment-prerequisites)."]]
