Destinations (SAP BTP)

Uma aplicação solicita uma destination pelo nome e recebe tudo de que precisa para fazer a chamada:

1. Um administrador cria a destination, por exemplo S4_ALDER, no subaccount ou em uma instância do Destination service.
2. A aplicação, vinculada a uma instância do Destination service, solicita S4_ALDER em tempo de execução.
3. O Destination service procura primeiro nas destinations dessa instância de serviço e, se não encontrar nenhuma, no subaccount.
4. O serviço devolve a configuração e, para muitos tipos de autenticação, os tokens de que a chamada precisa.
5. Com o tipo de proxy OnPremise, a chamada passa pelo Connectivity service e pelo SAP Cloud Connector; com o tipo de proxy Internet, ela sai diretamente.

Como a aplicação conhece apenas o nome, passar de teste para produção significa trocar a destination, não o código. As destinations do SAP BTP transformam detalhes de conexão em configuração sob responsabilidade das equipes de operação.

As propriedades adicionais de que uma destination precisa dependem da ferramenta consumidora e do cenário; o SAP Business Application Studio, por exemplo, só lista uma destination quando WebIDEEnabled está definida, e WebIDEUsage indica a ele para que a destination serve. Uma destination do SAP BTP é, portanto, um pequeno contrato entre a plataforma e cada ferramenta consumidora.

Pontos fortes

• Credenciais fora do código: segredos e certificados ficam na plataforma, e o cockpit consegue verificar a conexão.
• Um padrão para muitos destinos: APIs da internet, sistemas on-premise e instâncias de serviço do SAP BTP usam o mesmo objeto.
• Opções de identidade: principal propagation e fluxos OAuth permitem que o back-end veja o usuário real, em vez de uma conta compartilhada.

Onde elas param

• Configuração, não integração. Uma destination não mapeia dados, não repete chamadas nem monitora o fluxo de mensagens.
• Por subaccount. Cada subaccount precisa das próprias destinations. O cockpit pode exportar uma destination para um arquivo e importá-la em outro lugar, e o descritor MTA ou a API REST do Destination service podem criá-las, mas landscapes com muitos subaccounts ainda multiplicam a manutenção.
• Os direitos no back-end continuam valendo. Uma destination que funciona prova a conectividade, não que o usuário pode executar o serviço.

As destinations do SAP BTP padronizam a forma como os apps se conectam, enquanto a autorização e a lógica de processo ficam em outro lugar.

1. Usar o hostname real para destinos on-premise. A URL deve conter o host virtual e a porta definidos no SAP Cloud Connector, exatamente como mapeados.
2. Esquecer o location ID. Com vários connectors no subaccount, uma destination sem o location ID correto vai para a rede errada.
3. Nomes sobrepostos. Uma destination em uma instância de serviço com o mesmo nome de uma destination do subaccount vence a busca, o que confunde quem edita apenas a cópia do subaccount.
4. Usuários técnicos em todo lugar. Autenticação basic com um único usuário compartilhado esconde quem fez o quê no back-end; principal propagation ou OAuth baseado em usuário preserva a trilha de auditoria.
5. Copiar propriedades sem critério. Flags como HTML5.DynamicDestination ampliam o acesso a qualquer usuário logado e só devem ser definidas quando um cenário precisa delas.

A maioria dos incidentes com destinations se deve a uma divergência de nome ou de mapeamento que a verificação de conexão teria revelado.