L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Comment intégrer les données des applications Oracle Fusion Cloud dans un entrepôt de données
Alors que les organisations accélèrent la réduction de leur infrastructure interne, de la gestion des bases de données et des applications, nombre d'entre elles migrent leurs anciennes applications ERP, SCM, HCM et CX sur site vers les applications Oracle Fusion Cloud. Et il est très courant de voir de telles organisations déjà investies dans un entrepôt de données consolidé. Un entrepôt de données est généralement une cible commune de tous les ensembles de données provenant de diverses applications. Par conséquent, la migration des applications vers Oracle SaaS nécessite une bonne compréhension de l'état futur de l'entrepôt de données et du reporting, car ceux-ci coexistent avec l'architecture globale des systèmes. Certaines organisations ont évalué le fait de conserver leur entrepôt de données sur site tel quel, et donc de l'alimenter en données à partir d'applications Fusion. Bien que cela puisse sembler une approche plus facile à mettre en œuvre, par rapport à la construction d'un entrepôt de données à partir de zéro, elle présente des défis. En conséquence, beaucoup penchent davantage pour investir dans une approche plus futuriste de l'analyse, une approche compatible avec la modernité des applications Fusion et offrant la flexibilité, la gouvernance et les fonctionnalités avancées attendues par la communauté des affaires.
Que ce soit le La décision est de conserver votre entrepôt de données actuel et de l'alimenter en données d'applications Fusion Cloud, ou d'en créer un nouveau. Dans ce blog, je présenterai différentes approches pour extraire des données à partir d'applications Fusion Cloud. Chacune des approches présente certains avantages par rapport aux autres, en fonction de votre future architecture d'état et des applications source impliquées dans la consolidation des données pour le reporting. Mon objectif ici est de présenter ces caractéristiques différenciantes de chaque approche et donc d'aider à trouver la plate-forme la plus appropriée pour alimenter les données Fusion dans un entrepôt de données.
Le tableau ci-dessous compare six plates-formes différentes pour réaliser ce type d'intégration. Quelques remarques sur cette analyse :
- La synchronisation des données est répertoriée ci-dessous comme l'une des options. Bien qu'Oracle Data Sync 2.6.1 soit toujours disponible auprès d'Oracle pour téléchargement et soit actuellement pris en charge, il est considéré comme un outil obsolète. Pour votre feuille de route, vous êtes fortement encouragé à ne pas compter sur Data Sync pour votre future solution d'analyse d'état.
- Fusion Analytics Warehouse (FAW) n'est pas répertorié ci-dessous comme l'une des options. Cependant, FAW devrait être une option très viable à mettre en œuvre si vous utilisez les applications Fusion Cloud. Il propose un ETL pré-construit à partir d'applications Fusion vers un entrepôt de données autonome. De plus, son cadre d'extensibilité permet d'ajouter une personnalisation au niveau de l'entrepôt de données, du modèle sémantique et du tableau de bord. Il est exclu de cette analyse car il offre une solution de bout en bout et est entièrement géré par Oracle.
- BI Publisher : BI Publisher permet d'exporter des données à partir d'applications Fusion, mais il gère bien les cas d'utilisation limités. Il n'est pas recommandé comme approche générale pour intégrer les données des applications Fusion dans un entrepôt de données, en raison de la complexité de la gestion et de la maintenance d'un grand nombre de ces exportations de données.
| OAC Direct Query | OAC BICC Replication | Oracle Data Sync | OCI Data Integration | ODI Web (Data Transforms) | Incorta Oracle Cloud App Connector | |
| Nécessite l'installation et la maintenance de logiciels supplémentaires | Non | Non | Oui | Non | Oui | Non |
| Cloud Infrastructure | Oui | Oui | Oui (IaaS est facultatif) | Oui | Oui | Oui (IaaS est facultatif) |
| Cloud Platform | Oui – Oracle Managed | Oui – Oracle Managed | Non – La plateforme est gérée par le client | Oui – Oracle Managed[19659013]Non – La plate-forme est gérée par le client | Oui (PaaS est facultatif) | |
| Utilise Fusion OTBI | Oui : en temps réel | Non | Oui | Non | Non | Non |
| Utilise Fusion BICC | Non | Oui | Pas nativement, peut lire à partir du stockage d'objets OCI si BICC est configuré en dehors de Data Sync | Oui | Oui | Oui |
| Prend en charge les extraits des PVO Custom Fusion | No | Oui | Nécessite une configuration manuelle via BICC | With Parameters | Yes | Yes |
| Prend en charge les rapports en temps réel sur les données de fusion | Oui | Non | Non | Non | Non | Non |
| Prend en charge les charges incrémentielles | Non applicable | Oui | Oui | Oui | Oui | Oui |
| Prise en charge de la gestion des suppressions | Non applicable | Oui – gestion automatique native | Non | Oui – Nécessite une gestion personnalisée des suppressions | Oui – Nécessite une gestion personnalisée des suppressions | Oui – Nécessite une gestion personnalisée des suppressions |
| Prend en charge les modifications historiques suivies dans Fusion | Non applicable | Oui | Non | Oui, si la source PVO inclut des mises à jour historiques | Oui, si le PVO source inclut les mises à jour historiques | Oui, si le PVO source inclut les mises à jour historiques |
| Mana automatique gestion des exécutions BICC et des fichiers CSV exportés | Non applicable | Oui | Non | Oui | Oui | Les exécutions BICC sont gérées directement dans BICC, les fichiers CSV sont gérés par Incorta Connector |
| Prend en charge le filtrage des extraits | Oui | Oui | Oui | Oui | Oui | Oui |
| Prend en charge la planification des extractions de données | Non applicable | Oui | Oui[19659012]Oui | Oui | Oui | |
| Permet la transformation des données (comme joindre Fusion à des données non-Fusion pendant le chargement) | Non applicable | Non | Oui (prend également en charge l'approvisionnement auprès d'Amazon, Redshift, Apache Hive, Azure SQL DB, SQL Server, MySQL, Amazon S3, OCI Object Storage, PostgreSQL) | Oui (prend également en charge l'approvisionnement auprès de Parquet, Azure, SQL Server, PostgreSQL, Apache Hive et Amazon) | Oui (prend également en charge l'approvisionnement depuis Oracle DB, SM SQL Server, MySQL, Salesforce, NetSuite, Cassandra, Hypersonic SQL, IBM DB2 UDB, Informix)[19659014]Non (la transformation est possible après l'ingestion des données) | |
| Cibles de chargement de données prises en charge | Non applicable | BD Oracle (y compris Autonomous) | BD Oracle (y compris Autonomous), MySQL, OCI Object Storage (CSV, JSON, Parquet, Avro) | BD Oracle (y compris Autonomous), OCI Object Storage (CSV, JSON, Parquet, Avro) | Oracle DB, MS SQL Server, MySQL | Incorta Shared Storage (Fichiers Parquet)[19659120]  Source link |