Como resolver o problema de compartilhamento de recursos de origem cruzada ao consumir um serviço ODATA em um site da web com jQuery

Introdução

Depois de todas as introduções teóricas nos eventos recentes do SAP TechEd e em alguns projetos menores em um sistema de sandbox local, finalmente estava desenvolvendo meu próprio primeiro serviço ODATA baseado no Gateway que deveria ser consumido por algum site que executa jQuery. Configurar nosso pequeno serviço, criar algumas entidades, etc., não foi realmente algo especial depois de todas as introduções e o excelente material de aprendizagem no SCN.

Problemas do cenário do mundo real

Lá vamos nós, nossos colegas de desenvolvimento de sites incluíram o URI do serviço fornecido e estão tentando ler dados de nosso serviço. Nada acontece dentro do script de jQuery em comparação com chamar diretamente o serviço em um navegador, onde obtemos uma resposta agradável. O que aconteceu?

Ao olhar as excelentes ferramentas de desenvolvimento do Chrome, obtemos um indicador de nosso problema:

Continuamos nossa jornada com ferramentas do Google e finalmente terminamos obtendo informações realmente úteis sobre 'Compartilhamento de recursos de origem cruzada'. Recomendo dar uma olhada no seguinte:

• https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
• Resolvendo o problema da "Política de mesma origem" de diferentes maneiras por michaelherzog

Opções

Ao olhar a postagem do blog de michaelherzog Eu teria adorado usar JSONP (como descrito em um manipulador personalizado neste post). Infelizmente (segundo meu conhecimento) o NetWeaver Gateway atualmente não suporta JSONP e eu não queria desistir do framework completo do Gateway e escrever um manipulador do zero como descrito no blog mencionado por alessandro.spadoni .

Configurar um proxy no servidor que fornece o site teria sido uma opção, embora eu quisesse evitar isso por duas razões: carga adicional no servidor e ser capaz de resolver esse problema por conta própria dentro do Gateway.

Então, a próxima opção seria enviar um cabeçalho apropriado 'Access-Control-Allow-Origin' na resposta. Não consegui encontrar documentação específica do Gateway sobre personalização, então parecia que precisávamos lidar com isso por conta própria.

Adicionando o cabeçalho http

A primeira e mais atraente opção, é claro, seria adicionar o cabeçalho diretamente em nossa extensão de serviço. E a boa notícia é que realmente se pode fazer isso. Logo dentro de sua classe 'DPC_EXT' você tem acesso ao método /IWBEP/IF_MGW_CONV_SRV_RUNTIME~SET_HEADER que pode ser usado para definir campos de cabeçalho adicionais. Bem, e nossa primeira solução já está funcionando!

Ampliando a solução

Agora que temos a primeira solução no lugar, eu queria expandir isso um pouco para não enviar '*' como o solicitante permitido e com isso permitir que qualquer um que possa chamar meu servidor execute este serviço dentro de seu site. Em outras palavras, eu queria verificar o solicitante contra uma pequena tabela de clientes que permitiria potenciais consumidores do meu serviço. No entanto, não consegui acessar o campo de cabeçalho http necessário 'Origem' da solicitação para determinar o solicitante.

Em vez de usar o método de serviço da entidade, decidi escrever um pequeno manipulador http personalizado ao qual poderia me conectar em SICF e que verificaria o solicitante e, se estivesse correto, adicionaria o campo de cabeçalho. Não entrarei em detalhes sobre como escrever a classe de manipulador http em si. Isso deve estar suficientemente documentado por aqui.

No entanto, ao conectar o manipulador adicional em SICF, me deparei com os seguintes problemas que gostaria de compartilhar para tornar a vida um pouco mais fácil.

Ordem de execução de classes de manipulador e fluxo de manipuladores

Em primeiro lugar, nossa pequena classe de manipulador deve ser executada antes do manipulador padrão /IWFND/CL_SODATA_HTTP_HANDLER. Caso contrário, nunca será alcançado porque após a execução do manipulador padrão, o atributo if_http_extension~flow_rc será definido como 0 (