Intégration à Oracle EBS

L'intégration à Oracle EBS (E-Business Suite) est compatible avec les modèles de données Order to Cash (de la commande à l'encaissement) avec l'ingestion de données à l'aide de Incorta. Incorta utilise une instance hébergée ou privée pour ingérer les données d'Oracle dans un ensemble de données CDC BigQuery et gère le traitement CDC. Ensuite, Cortex Framework transforme et matérialise les données CDC en actifs de reporting à l'aide de Managed Service for Apache Airflow pour orchestrer les tâches BigQuery.

Le schéma suivant décrit comment les données Oracle EBS sont disponibles via la charge de travail opérationnelle Oracle EBS :

Source de données Oracle EBS

Figure 1. Présentation de l'intégration Cortex Framework-Oracle EBS-Incorta .

Configuration du déploiement

Le tableau suivant présente les paramètres de configuration de la charge de travail Oracle EBS : Le config.json fichier configure les paramètres requis pour transférer des données depuis n’importe quelle source de données, y compris Oracle EBS. Ce fichier contient les paramètres suivants pour Oracle EBS :

Paramètre Signification Valeur par défaut Description Champ source Oracle correspondant
OracleEBS.itemCategorySetIDs Ensembles de catégories d'articles [1100000425] Liste des ensembles à utiliser pour catégoriser les articles. MTL_ITEM_CATEGORIES.CATEGORY_SET_ID
OracleEBS.currencyConversionType Type de conversion de devise "Corporate" Type de conversion de devise à utiliser dans les tables agrégées. GL_DAILY_RATES.CONVERSION_TYPE
OracleEBS.currencyConversionTargets Cibles de conversion de devise ["USD"] Liste des devises cibles à inclure dans les tables agrégées. GL_DAILY_RATES.TO_CURRENCY
OracleEBS.languages Langues ["US"] Liste des langues dans lesquelles présenter les traductions de champs tels que les descriptions d'articles. FND_LANGUAGES.LANGUAGE_CODE
OracleEBS.datasets.cdc Ensemble de données CDC - Ensemble de données CDC. -
OracleEBS.datasets.reporting Ensemble de données de reporting "REPORTING_OracleEBS" Ensemble de données de reporting. -

Ingestion de données

Contactez un représentant Incorta et consultez le guide de configuration d'Oracle EBS pour Google Cortex afin d'obtenir des informations sur l'ingestion de données d'Oracle dans BigQuery.

Bien qu'Incorta soit compatible avec la planification des tâches d'ingestion de données à différents intervalles, pour des performances et une actualisation des données optimales, nous vous recommandons de planifier l'exécution quotidienne des tâches d'ingestion de données Incorta. Si votre cas d'utilisation nécessite la gestion des données supprimées, veillez à les activer en suivant les instructions de la documentation Incorta, Gestion des suppressions de sources.

Configurations de reporting

Cette section décrit les configurations de reporting nécessaires pour votre environnement.

Connexion Airflow Managed Airflow

Créez une connexion BigQuery Airflow nommée oracleebs_reporting_bq qui sera utilisée par l'opérateur BigQuery pour effectuer des transformations de reporting. Pour en savoir plus, consultez la documentation Gérer les connexions Airflow.

Paramètres de matérialisation

Recherchez les paramètres de matérialisation dans src/OracleEBS/config/reporting_settings.yaml. Par défaut, les tables de dimensions, d'en-tête et agrégées sont matérialisées quotidiennement. Les tables de la couche de reporting sont également partitionnées par date. Si nécessaire, vous pouvez personnaliser les partitions et le clustering. Pour en savoir plus, consultez les pages Paramètres de cluster et Partitionnement des tables.

Modèle de données

Cette section décrit le modèle de données logique Oracle EBS Order to Cash. Chaque sous-section explique le diagramme de relation d'entité (ERD) Oracle EBS suivant.

Diagramme entité-relation pour Oracle EBS

Figure 2. Oracle EBS : diagramme de relation d'entité.

Vues de faits de base

Il s'agit des objets bleus du diagramme de relation d'entité. Ce sont des vues sur les tables CDC sans autre transformation que certains alias de noms de colonnes.

Tables de dimensions

Il s'agit des objets violets du diagramme de relation d'entité. Ils contiennent les attributs dimensionnels pertinents utilisés par les tables de reporting. Par défaut, ces dimensions sont filtrées en fonction des valeurs des paramètres de configuration du déploiement , le cas échéant. Cette intégration utilise également la dimension du calendrier grégorien Cortex K9 pour les attributs de date, qui est déployée par défaut.

Tables d'en-tête

Il s'agit des objets verts du diagramme de relation d'entité. Ils contiennent les faits et les dimensions joints qui décrivent les entités commerciales telles que les commandes et les factures au niveau de l'en-tête. Les tables d'en-tête sont partitionnées par une date d'événement principale correspondant à chaque entité, par exemple ORDERED_DATE ou INVOICE_DATE.

Lignes imbriquées et répétées

Les tables SalesOrders et SalesInvoices contiennent des champs répétés imbriqués nommés LINES. Ces champs regroupent les différentes lignes de commande et lignes de facture sous leurs en-têtes associés. Pour interroger ces champs imbriqués, utilisez l'UNNEST opérateur pour aplatir les éléments en lignes, comme indiqué dans les exemples de scripts fournis (src/OracleEBS/src/reporting/ddls/samples/).

Attributs imbriqués et répétés

Certaines tables contiennent des champs répétés imbriqués supplémentaires tels que ITEM_CATEGORIES ou ITEM_DESCRIPTIONS, où plusieurs valeurs du même attribut peuvent s'appliquer à l'entité. Si vous désimbriquez ces attributs répétés, veillez à filtrer une seule valeur d'attribut pour éviter de surcompter les mesures.

Comptes clients appliqués

SalesAppliedReceivables est une table unique dans la mesure où les entités peuvent référencer des factures seules ou une facture avec un encaissement. Par conséquent, il existe des champs INVOICE et CASH_RECEIPT imbriqués (mais non répétés), où le champ CASH_RECEIPT n'est renseigné que lorsque APPLICATION_TYPE = 'CASH'.

Tables agrégées

Il s'agit des objets rouges du diagramme de relation d'entité. Ils agrègent les données des tables d'en-tête jusqu'aux mesures quotidiennes. Chacune de ces tables est également partitionnée par une date d'événement principale. Les tables agrégées ne contiennent que des mesures additives (par exemple, des nombres, des sommes) et n'incluent pas de mesures telles que les moyennes et les ratios. Cela signifie que les utilisateurs doivent dériver les mesures non additives pour s'assurer qu'elles peuvent être dérivées de manière appropriée lors de l'agrégation à un niveau plus élevé, par exemple mensuel. Consultez des exemples de scripts tels que src/OracleEBS/src/reporting/ddls/samples/SalesOrderAggMetrics.sql.

Montants de conversion de devise

Chaque table agrégée utilise la dimension CurrencyRateMD pour créer un champ répété imbriqué AMOUNTS contenant des mesures de devise converties dans chacune des devises cibles spécifiées dans la configuration du déploiement. Lorsque vous utilisez ces mesures, veillez à filtrer une seule devise cible ou à regrouper les devises cibles pour le reporting afin d'éviter de surcompter. Cela est également visible dans les exemples de scripts tels que src/OracleEBS/src/reporting/ddls/samples/SalesOrderAggMetrics.sql.

Attributs et mesures de ligne imbriqués

La table SalesOrdersDailyAgg contient un champ répété imbriqué nommé LINES pour faire la distinction entre les attributs et les mesures au niveau de la ligne (par exemple, ITEM_CATEGORY_NAME et AMOUNTS) et les attributs et les mesures au niveau de l'en-tête (par exemple, BILL_TO_CUSTOMER_NAME et NUM_ORDERS). Veillez à interroger ces niveaux séparément pour éviter de surcompter.

Bien que les factures aient également une notion d'en-têtes par rapport aux lignes, la table SalesInvoicesDailyAgg ne contient que des mesures au niveau de la ligne. Elle ne suit donc pas la même structure que SalesOrdersDailyAgg.

Étape suivante