Vers une meilleure intégration du Cloud Oracle EPM

Oracle a la volonté de basculer l’ensemble de sa base installée vers ses solutions Cloud pour cette nouvelle année.

Quelques obstacles subsistent, le principal étant l’intégration aux architectures, dans des approches hybrides totalement intégrées.

La solution actuelles des « demi-interfaces » via fichiers plats (qui sont robustes, voire pratiques) reste limitée faisant des Cloud EPM , des « impasses applicatives ».

La solution arrive car, au Kscope19 (conférence des développeurs) de juin, Oracle a annoncé la publication prochaine d’un agent d’intégration on-premise pour l'EPM en Cloud, qui permettra aux clients de se connecter à des sources de données hébergées chez eux.

Cet agent se présentera sous la forme d'un logiciel discret, similaire à EPM Automate, installé sur un petit serveur ou une machine virtuelle où il pourra accéder à vos systèmes sources hébergés chez vous. La définition des sources de données, des requêtes et des filtres sera stockée dans EPM Cloud, afin que la configuration nécessaire sur site sera vraiment minimale. Des requêtes pour EBS et PeopleSoft GL seront pré-configurées et l'agent pourra également accéder à toute autre source de données via des requêtes SQL personnalisées.

L'EPM en Cloud pourra communiquer avec l'agent selon deux méthodes :

Mode synchrone :

Si EPM Cloud peut accéder directement au port sur lequel l'agent écoute, alors dès que l'utilisateur clique sur "Importer" dans l'EPM Cloud :

• EPM Cloud envoie une requête à l'agent avec un ProcessID (c'est la seule communication allant du cloud vers l'agent). L'agent demandera les détails du travail (SQL et paramètres) à EPM Cloud en se référant à ce ProcessID.
• L'agent traitera la demande. Des traitements en amont et en aval sont également possibles (similaire à ce qui était possible avec FDMEE on-premise)
• L'agent charge les données sur le Cloud
• Les données sont traitées de la même manière qu’elles le seraient actuellement avec des chargements par fichiers plats ou par EPM Automate (groupes logiques, mapping, validation, export, rapports, etc.).

Ce mode synchrone est simple, mais cela implique qu'un serveur interne soit accessible à partir de l'internet public et demandera de paramétrer une DMZ avec un pare-feu et un serveur HTTP pour garantir que seul ce port spécifique sur ce serveur spécifique soit accessible.

Mode asynchrone :

Si vous ne pouvez pas obtenir les autorisations de votre service sécurité informatique pour que le mode synchrone fonctionne, ce sera votre plan B.

Dans ce mode, aucune communication de l'extérieur vers le réseau interne n'est nécessaire. Au lieu de cela, l'agent interroge périodiquement une file d'attente dans le cloud et exécute les demandes qu'il trouve dans cette file d'attente. Lorsque l'utilisateur clique sur "Importer" dans EPM Cloud:

• EPM Cloud met la requête (SQL et paramètres) en file d'attente
• L'agent interroge la file d'attente à un intervalle défini par le client.

Si un travail est dans la file d'attente, l'agent récupère le SQL et les paramètres. Après quoi le processus est identique à ce qu’il est en mode synchrone :

• L'agent traitera la demande. Des traitements en amont et en aval sont également possibles (similaire à ce qui était possible avec FDMEE on-premise)
• L'agent charge les données dans le cloud. Les données sont traitées de la même manière qu’elles le seraient actuellement avec des fichiers plats ou des téléchargements automatisés EPM (groupes logiques, mappage, validation, exportation, rapports, etc.).
• Les données sont traitées de la même manière qu’elles le seraient actuellement avec des chargements par fichiers plat ou par EPM Automate (groupes logiques, mapping, validation, export, rapports, etc.).

Le facteur clé de prise de décision pour décider d’utiliser l’option synchrone ou asynchrone est sans conteste ce que votre sécurité informatique vous permettra de faire.

Oracle a prêté attention aux préoccupations des services informatiques en minimisant les communications du Cloud vers l'agent hébergé chez vous et en veillant à ce que toute communication entre l'EPM Cloud et l'agent soit cryptée.

Un autre facteur à prendre en compte est que l'option de drill down, permettant d'afficher les données de la source dans une boîte de dialogue de l'EPM Cloud, ne sera disponible qu'en mode synchrone. Un facteur de décision important.

Les options de pré et post-traitement, utilisant du Jython ou du Groovy, ainsi que la possibilité de définir vos propres requêtes SQL pour les sources de données qui ne sont pas prévues avec l'intégration prédéfinie permettront à nos clients d'intégrer directement des données pour n'importe quel système source, comme avec FDMEE.

En tant qu’intégrateur, nous sommes sur les « starting block » pour proposer ce type de solution à nos clients, car la demande est forte.

Le Cloud est désormais une évidence, ce type de solution, gage d’ouverture et de flexibilité, permet d’envisager sa généralisation à grande échelle sur le marché français.

Rendez-vous sur le site Klee Performance (rubrique Actus) pour d’autres « avis d’expert » issus d’Oracle Open World.

Sources : Julien Coudrette, document Oracle & Kscope.