Y a-t-il un avantage à utiliser des appels RFC directs au lieu de BAPI?

Question

Je ne suis pas très familier avec le travail sur SAP, mais ma tâche actuelle est d'utiliser des appels RFC pour créer des bons de commande dans le logiciel SAP via un projet C# sur lequel je travaille.

Y a-t-il un avantage à utiliser des appels RFC directs plutôt que le BAPI ? J'ai posé la question à mon superviseur et sa raison était "éviter le désordre inutile/inconnu".

Notre ancien programme utilisait le BAPI. Je trouve avec cette tâche que je me retrouve à courir en rond en plongeant dans les métadonnées et en résolvant les problèmes liés à l'utilisation/à l'obtention des structures dont j'ai besoin.

Les choses avancent et fonctionnent, mais je ne comprends pas pourquoi il est si important d'utiliser RFC plutôt que BAPI.

Édition pour clarifier mon vocabulaire inapproprié : nous utilisons actuellement un wrapper qui appelle le BAPI pour nous. Ma tâche consiste à ne pas utiliser le wrapper mais à utiliser les mêmes appels RFC que le BAPI utiliserait.

Exemple:

IRfcFunction poCreateFunction = _dest.Repository.CreateFunction("BAPI_PO_CREATE1");
IRfcStructure poHeader = poCreateFunction.GetStructure("POHEADER");
poCreateFunction.SetValue("POHEADER", poHeader);
...
poCreateFunction.Invoke(_dest);

Answer 1

Une réponse techniquement correcte, mais quelque peu peu utile serait ?ERREUR DE SYNTAXE, suivie d'un énorme curseur bleu clignotant.

Les BAPI sont des modules de fonction RFC-enabled, il n'y a donc aucune différence technique entre l'appel à un BAPI et à tout autre module de fonction RFC-enabled. La différence réside dans le fait que les BAPI sont officiellement publiés pour une utilisation par les clients et les partenaires. Ils sont pris en charge, maintenus et pour la plupart bien documentés - par opposition à un module de fonction interne qui, pour certaines raisons techniques, doit être RFC-enabled. Il existe un ensemble strict de règles que tout développeur souhaitant fournir un BAPI doit respecter afin de maintenir un certain ensemble de normes tout au long de l'interface de programmation. Il est vrai que les BAPI ont des noms de paramètres plutôt longs et des structures de données énormes pour couvrir toutes sortes d'applications spéciales, mais qualifier cela de "désordre" ne laisse pas une impression positive...

Answer 2

Votre superviseur vous a donné une réponse très à moitié faite, et cela vous fait vous demander s'il comprend ce qu'il essaie d'accomplir en vous obligeant à utiliser des RFC personnalisés (je suppose).

Dans les projets intégrés .NET, en tant que programmeur ABAP, je fournis souvent des modules RFC d'enrobage pour masquer une partie de la complexité des BAPI, ou parce que le côté .NET peut ne pas avoir toutes les informations nécessaires pour la BAPI. Cela se traduit souvent par une interface plus simple, mais avec des fonctionnalités limitées. Mais à la fin, cela ne fait que déplacer l'appel BAPI de .NET vers la pile ABAP.

Si vous rencontrez des problèmes avec les modules de fonction RFC fournis qui ne se produisent pas lorsque vous utilisez les BAPI, il y a probablement quelque chose qui ne va pas avec le module de fonction. Ou du moins, il ne remplit pas le but de cacher la complexité de SAP au programme .NET et ne vous apporte aucun avantage par rapport à l'utilisation des BAPI standard, qui sont du moins bien documentées et pris en charge.