Destinations (SAP BTP)

Une application demande une destination par son nom et reçoit tout ce dont elle a besoin pour effectuer l'appel :

1. Un administrateur crée la destination, par exemple S4_ALDER, dans le sous-compte ou sur une instance du Destination service.
2. L'application, liée à une instance du Destination service, demande S4_ALDER à l'exécution.
3. Le Destination service recherche d'abord parmi les destinations de cette instance de service puis, s'il n'en trouve aucune, dans le sous-compte.
4. Le service renvoie la configuration et, pour de nombreux types d'authentification, les jetons nécessaires à l'appel.
5. Avec le type de proxy OnPremise, l'appel passe par le Connectivity service et SAP Cloud Connector ; avec le type de proxy Internet, il sort directement.

Comme l'application ne connaît que le nom, passer du test à la production revient à modifier la destination, pas le code. Les destinations SAP BTP transforment les détails de connexion en configuration dont les équipes d'exploitation sont responsables.

Les propriétés supplémentaires nécessaires dépendent de l'outil consommateur et du scénario ; SAP Business Application Studio, par exemple, n'affiche une destination que si WebIDEEnabled est défini, et WebIDEUsage lui indique à quoi sert la destination. Une destination SAP BTP est donc un petit contrat entre la plateforme et chaque outil consommateur.

Points forts

• Identifiants hors du code : les secrets et les certificats restent dans la plateforme, et le cockpit peut vérifier la connexion.
• Un seul pattern pour de nombreuses cibles : les API internet, les systèmes on-premise et les instances de service SAP BTP utilisent le même objet.
• Options d'identité : la propagation du principal et les flux OAuth permettent au back-end de voir l'utilisateur réel au lieu d'un compte partagé.

Limites

• De la configuration, pas de l'intégration. Une destination ne mappe pas les données, ne relance pas les appels et ne supervise pas les flux de messages.
• Par sous-compte. Chaque sous-compte a besoin de ses propres destinations. Le cockpit peut exporter une destination vers un fichier et l'importer ailleurs, et le descripteur MTA ou l'API REST du Destination service peuvent les créer, mais les paysages comptant de nombreux sous-comptes multiplient malgré tout la maintenance.
• Les droits du back-end s'appliquent toujours. Une destination fonctionnelle prouve la connectivité, pas que l'utilisateur est autorisé à exécuter le service.

Les destinations SAP BTP standardisent la manière dont les applications se connectent, tandis que l'autorisation et la logique de processus restent ailleurs.

1. Utiliser le nom d'hôte réel pour les cibles on-premise. L'URL doit reprendre l'hôte virtuel et le port définis dans SAP Cloud Connector, exactement tels qu'ils sont mappés.
2. Oublier le location ID. Avec plusieurs connecteurs dans le sous-compte, une destination sans le bon location ID aboutit sur le mauvais réseau.
3. Noms masqués. Une destination sur une instance de service portant le même nom qu'une destination du sous-compte l'emporte lors de la recherche, ce qui déroute quiconque ne modifie que la copie du sous-compte.
4. Des utilisateurs techniques partout. L'authentification basique avec un seul utilisateur partagé masque qui a fait quoi dans le back-end ; la propagation du principal ou un OAuth basé sur l'utilisateur préserve la piste d'audit.
5. Copier les propriétés à l'aveugle. Des indicateurs comme HTML5.DynamicDestination ouvrent l'accès à tout utilisateur connecté et ne doivent être définis que lorsqu'un scénario en a besoin.

La plupart des incidents liés aux destinations remontent à une incohérence de nom ou de mapping que la vérification de connexion aurait révélée.