Service Binding (RAP)

Un service binding est la dernière étape de la chaîne RAP qui va du modèle de données au service consommable :

1. Des CDS view entities et une behavior definition forment le business object.
2. Des projection views définissent ce dont un service a besoin.
3. Une service definition liste les entités que le service expose.
4. Le service binding détermine comment ce périmètre est exposé : quel protocole, quel type de consommation et quelle version.

Ses paramètres sont le nom du service, identique au nom du binding ; le type de binding ; la version du service ; et le statut de publication. Comme le protocole et le périmètre sont des objets distincts, plusieurs bindings peuvent reposer sur une même service definition : Alder Manufacturing pourrait exposer le même périmètre de demande d'achat une fois comme service UI OData V4 pour son application SAP Fiori, et une fois comme Web API OData V4 pour un portail fournisseurs de Cedar Office Supply. Le service binding est donc l'endroit où un service RAP devient un endpoint concret et adressable.

La documentation SAP actuelle répertorie quatre protocoles et deux catégories de consommation :

La catégorie compte autant que le protocole. Les services UI portent dans leurs métadonnées les annotations d'interface, les aides à la saisie, les side effects et le feature control, et proposent l'aperçu SAP Fiori elements. Les Web API ne contiennent aucune information propre à l'interface, sont destinées à des consommateurs inconnus et peuvent être étendues. SAP recommande OData V4 partout où c'est possible pour les services transactionnels, et précise que la prise en charge complète de SAP Fiori elements sur OData V4 n'est assurée que pour les scénarios avec draft. Vérifiez dans la documentation RAP de votre release quels types de binding elle propose. Critère de décision : choisissez un binding UI lorsqu'une application SAP Fiori consomme le service, et un binding Web API dans tous les autres cas.

• Publication : le binding doit être actif, et le bouton Publish de l'éditeur de service binding exécute les task lists qui activent l'endpoint. SAP souligne que la publication n'active le service que dans le système courant ; elle ne le rend pas accessible depuis d'autres systèmes.
• Après transport (on-premise et Private Edition) : SAP documente que le service binding n'active le service qu'en local, dans le système de développement ; dans les systèmes de qualification et de production, le service est activé avec les outils Gateway, les services OData V4 comme groupes de services dans /IWFND/V4_ADMIN et les services OData V2 dans /IWFND/MAINT_SERVICE.
• Environnement ABAP (SAP BTP et extensibilité développeur de la Public Edition) : une Web API atteint les appelants externes via l'inbound service généré par le binding, ajouté à un communication scenario publié, puis via un communication arrangement créé par un administrateur.
• Gestion des versions : ajouter une autre service definition à un binding existant crée la version suivante du service, de sorte que les modifications atteignent les nouveaux consommateurs sans casser les existants.

Un service binding publié est un endpoint local ; l'exposition à d'autres systèmes est une étape de configuration distincte.

1. Lier une application SAP Fiori à une Web API. L'application se charge mais affiche des tableaux vides ou des mises en page par défaut, car les métadonnées Web API ne contiennent aucune annotation d'interface. Créez un binding UI.
2. Choisir OData V4 pour une application transactionnelle sans draft. La prise en charge de SAP Fiori elements en V4 n'est complète qu'avec le draft ; activez le draft ou prévoyez des lacunes.
3. Modifier sur place un service libéré. Les consommateurs cessent de fonctionner sans signal. Ajoutez plutôt une version de service.
4. Supposer que Publish signifie accessible. Un appelant distant a toujours besoin d'une configuration de communication, et en on-premise les utilisateurs ont besoin d'autorisations pour le service.
5. Déboguer d'abord l'interface. Lorsqu'un aperçu échoue, vérifiez que le binding est actif et publié avant de toucher aux annotations.

La plupart des problèmes de service binding proviennent du choix de la mauvaise catégorie ou d'une étape de publication omise, et non du business object qui se trouve derrière.