Vous utilisez la dernière version de SAP BPC ? C’est bien. Vous avez fini d’implémenter votre projet de planification et/ou de consolidation budgétaire sur l’environnement de DEV ? Tant mieux. Les tests usine sont concluants ? Bravo ! Il est temps maintenant de transporter en QUAL… ou en PROD, selon les paysages systèmes dont vous disposez.

Mais au fait, que connaissez-vous des nouveautés liées aux transports sur la version SAP BPC 10 ? C’est justement le sujet sur lequel nous allons nous pencher.

Flexibilité et performance

Le principe de transport d’un projet développé sur SAP BPC 10 est très proche de celui d’un projet BW, à savoir une flexibilité dans le process d’import. Oui, car autant avec les versions précédentes de BPC, il était nécessaire de transporter l’AppSet dans son intégralité, autant la nouvelle version du produit permet une souplesse quasi-révolutionnaire pour ceux qui ont connu la transaction UJBPCTR.

En effet, il est désormais possible d’exploiter  la granularité des objets transportés en ne collectant que les composants souhaités.

Concrètement : vous avez besoin de modifier une dimension de votre projet BPC. Hier, avec les versions 7.X, vous deviez vous embarrasser à transporter toute l’Appset. Fastidieux, n’est-ce pas ? Aujourd’hui, avec BPC 10, le processus est à la fois facilité et maîtrisé. Vous ne transportez que ce dont vous avez réellement et spécifiquement besoin.

Conséquence évidente de cette nouvelle possibilité : un gain de performance net sur les temps d’import.

Un concept standardisé

C’est LA bonne nouvelle pour les consultants BPC familiers de BW : le concept de transport dans SAP BPC 10 est bel et bien intégré au standard NetWeaver CTS de BW 7.3 (Change and Transport System).

Les objets BPC sont collectés via le « Lien au Transport » classique (RSA1 > Lien au Transport >> SAP Transport >>> Types d’objet >>>> Plus de types).

A noter que le système crée des ordres de Customizing pour les objets BPC.

L’administration des ordres de transport s’effectue par les transactions usuelles SE01, SE09, SE10 et STMS (si les droits sont affectés).

En termes de maintenance, il faut retenir la possibilité de créer des ordres de transport de suppression, toujours avec le même esprit de cibler la granularité souhaitée.

Encore un avantage : outre le protocole d’import STMS, vous avez le moyen de débugger les éventuels problèmes rencontrés lors de la phase d’imports. Pour cela,

  • Se connecter au système source du transport
  • Transaction SLG1
  • Saisir « UJ » dans le champ Objet et « UJT » dans le champ Sous-objet
  • Exécuter et analyser le protocole détaillé

Ceci dit, les problèmes de transports peuvent avoir des causes très variées. Et si l’étude du protocole peut parfois mener à des explications tangibles, il est préférable d’avoir des notions sur les contrôles de dépendance effectués par le système.

Une liberté sous contrôle

Flexibilité, performance, standardisation. Le consultant BPC a incontestablement gagné en privilèges grâce à cette nouvelle version. Mais tous ces avantages ne vont pas sans quelques contraintes naturelles liées à tous les contrôles internes opérés par SAP pour fiabiliser la qualité des transports. Nous allons d’ailleurs nous projeter sur les potentielles erreurs que peut générer le système.

Vous avez transporté vos objets dans l’environnement cible, mais le protocole d’import signale des erreurs. Commencez par éliminer l’hypothèse d’une mauvaise configuration du système en contrôlant les points suivants :

  • Votre niveau de Support Package du système BW 7.3 est supérieur au SP02, (sinon, il faudra implémenter la note OSS 1537619)
  • Le système de transport a été correctement paramétré par votre administrateur (routes des transports, destination RFC, transaction RSTPRFC…).

Les problèmes liés aux autorisations sont très souvent dus à un paramétrage défecteux de l’administrateur de votre système. Si celui-ci n’est pas familier de l’acronyme BPC, vous pourrez lui indiquer le point de paramétrage SPRO correspondant :

A l’identique des transports BW, SAP procède à des contrôles de dépendance entre les objets BPC. Le système vérifie la cohérence et anticipe le résultat de l’import. Il y a trois types de contrôles :

  • Contrôles de dépendance lors de la création de l’ordre
  • Contrôles de dépendance lors du traitement d’import
  • Traitement de contrôle de données exécuté (la fameuse méthode AFTER_IMPORT bien connue des consultants BW)

On comprendra naturellement qu’un modèle BPC sera transporté correctement vers un environnement cible seulement si les dimensions qui le composent ont déjà été transportées unitairement ou bien si elles sont incluses dans le même ordre que le modèle. Si ce n’est pas le cas, une erreur d’import est plus que probable.

ATTENTION ! A l’inverse des objets BW, les objets BPC collectés dans les ordres de transports ne sont pas bloqués. Il est  donc impératif de rester vigilant sur la gestion de version des composantes BPC et la séquence d’import, laquelle devra respecter une logique garantissant la configuration souhaitée sur le système cible. Un effort de documentation permettra, par exemple, une meilleure traçabilité des objets et évitera des conflits ou régressions dans les développements.

Les consultants BW aguerris à la STMS et aux transports en général sauront normalement adopter les bons réflexes vis-à-vis de cette problématique.

Voilà, vous avez maintenant les clés pour réussir l’intégration de votre projet BPC sur les environnements de pré-production et de production.

NB : Sachez que pour les accros irrémédiables de la transaction UJBPCTR de la version 7.5, il est toujours envisageable de faire vos transports par ce biais. Mais si vous adoptez les nouvelles fonctionnalités de transport de SAP BPC 10, on pourra dire que « vous avez tout compris »…

Laisser un commentaire