Avalados por :

Como enviar imagens para uma API de reconhecimento óptico de caracteres da SAP com sucesso

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 4 Vistas
0
Cargando...

Hi Experts,

Tenho um caso de uso em que estou chamando um endpoint da CPI, passando a URL de uma imagem jpeg hospedada (como esta: http://braiden.net/images/img.jpg ) e então faço uma solicitação GET para essa URL usando uma solicitação-resposta para obter os dados da imagem bruta no corpo da mensagem.

Construí com sucesso essa parte. Agora que tenho esses dados de imagem bruta no corpo da mensagem, gostaria de fazer uma solicitação-resposta ao serviço de Reconhecimento Óptico de Caracteres da SAP ( documentado aqui ).

Esta API requer que a solicitação seja formatada da seguinte maneira:

•Content-Type: multipart/form-data; boundary=CPI

•APIKey: [alguma-chave-api-válida]

•Content-Length: [comprimento-do-conteúdo]

  • Deve conter um corpo de formulário múltiplo, com um único campo chamado "files" que contenha os dados da imagem

Devido aos requisitos da solicitação para esta API, adicionei um modificador de conteúdo para remover todos os cabeçalhos desnecessários (que podem ter sido trazidos da primeira solicitação) e adicionar os cabeçalhos necessários. (Parece que o cabeçalho "Content-Length" é adicionado automaticamente pela CPI, e qualquer tentativa de alterar/remover este cabeçalho não funciona).

Dentro deste modificador de conteúdo, também adicionei o seguinte no corpo como uma expressão:

--CPI
Content-Disposition: form-data; name="files"; filename="img.jpg"
Content-Type: image/jpeg

${body}
--CPI--

Isso envolve os dados da imagem bruta com as informações de limite necessárias para o tipo de conteúdo multipart/form-data. (Este método de envolver dados brutos foi retirado de esta postagem no blog .)

Aqui está uma imagem do meu fluxo de integração:

Clique aqui para baixar este fluxo de integração como um arquivo zip.

Uma coisa que notei é que ao enviar a solicitação do Postman versus fazer a solicitação da CPI é que o valor do cabeçalho Content-Length é drasticamente diferente, e como mencionei, parece não haver maneira de definir manualmente este cabeçalho para um valor diferente.

Também notei que ao visualizar a solicitação HTTP bruta feita pela CPI, os dados da imagem são ligeiramente diferentes dos dados da imagem ao enviá-los usando um Cliente REST. Há alguns caracteres faltando de vez em quando na solicitação feita pela CPI.

Aqui estão dois exemplos das solicitações, uma enviada de um Cliente REST, a outra enviada pela CPI. A solicitação do Cliente REST funciona ao ser enviada para a API de OCR, mas a solicitação da CPI não (retorna um erro 500).

Solicitação do Cliente REST

Solicitação da CPI

Novamente, as diferenças são o valor do cabeçalho Content-Length e alguns caracteres faltando na solicitação da CPI.

Aqui estão algumas perguntas:

1. Estou usando uma solicitação-resposta para obter os dados da imagem bruta da maneira correta para armazenar a imagem no corpo da mensagem, ou há um método melhor?

2. Como posso enviar corretamente esta imagem para a API de OCR? Até agora, só tenho recebido erros 500 do servidor da API de OCR.

3. Devo usar um codificador MIME Multipart ou um script para modificar a codificação? Se sim, como?

TL;DR: Quero enviar uma imagem para um API de reconhecimento óptico de caracteres.

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

4 Respuestas

0
Cargando...

°Olá Eng Swee!

Obrigado pelo seu contínuo apoio.

°Você estava certo! °O Content-Modifier é definitivamente o culpado! Curiosamente, se você ainda incluir o Content-Modifier no iflow, mas deixar o corpo como simplesmente:

${body}

os dados passam perfeitamente como se o Content-Modifier não estivesse lá. Isso é ótimo porque ainda posso usar um Content-Modifier para manipular os cabeçalhos sem corromper os dados no corpo. Mas quando você introduz algum outro texto, corrompe os dados da imagem, por exemplo:

${body}SomeText

(Verifiquei essas descobertas usando o método de transferência SFTP e usando o HxD)

øVocê sabe de alguma maneira de recuperar o corpo como uma matriz de bytes usando um script groovy e modificá-lo para adicionar as informações do corpo multipart, evitando a conversão para uma string?

Se você achar que seria benéfico, posso publicar isso como uma pergunta separada aqui agora que identificamos o problema na esperança de que outros forneçam sua opinião (já que essa pergunta provavelmente perdeu um pouco de tração devido à sua antiguidade).

Obrigado,

Braiden

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá braidenspencer

Baixei seu IFlow e dei uma olhada, e minha próxima "suspeita" seria no Modificador de Conteúdo. Você está construindo o corpo multipart aí, mas minha preocupação é que a avaliação do ${body} linha pode ser submetida a uma codificação binária em string que poderia corromper o conteúdo potencialmente.

Vou testar isso também do meu lado para ver como vai.

Saudações

Eng Swee

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Eng Swee,

Obrigado pela sua resposta rápida e detalhada.

Sim, é algo como um cenário estranho! Para ser mais específico, tenho um chatbot criado com SAP Conversational AI e quero utilizar o CPI para lidar com a lógica backend do chatbot. Os usuários podem interagir com o chatbot através de canais móveis como o Facebook Messenger. Quando o usuário envia uma foto, o Facebook Messenger fornece um link para a foto hospedada na rede de distribuição de conteúdo do Facebook. O chatbot então encaminha essa URL para o CPI.

De qualquer forma, segui sua sugestão e encaminhei a mensagem para um servidor SFTP logo após o primeiro request-reply. Como resultado, recebi a imagem corretamente sem corrupção e pude visualizá-la. Baixei o HxD, e ambos os arquivos parecem ser idênticos:

Com isso, o problema não parece estar no primeiro request-reply.

Outra coisa que tentei foi codificar os dados da imagem como uma string base64 e chamar o decodeBase64 nela para obter os dados brutos e armazená-los no corpo da mensagem usando um script groovy. Em seguida, alimentei essa mensagem pelo restante do iflow, mas quando chega a hora de fazer o request-reply para a API de OCR, a solicitação falha novamente com um erro interno do servidor. Você tem alguma outra sugestão?

Obrigado pelo seu apoio.

Saudações,

Braiden Psiuk

from-cpi.png from-web.png
Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Olá Braiden

Você tem um cenário muito interessante ?

Não tenho uma resposta direta, mas gostaria de oferecer minha sugestão com base na análise do que você forneceu.

Compare os arquivos que você forneceu e procure as diferenças de caracteres em um editor hexadecimal (por exemplo, HxD). A solicitação do cliente REST possui caracteres adicionais EF BF BD que são considerados o Caractere de substituição Unicode (U+FFFD) . Não tenho certeza por que o cliente REST tem isso enquanto o CPI não.

Recomendaria dividir o cenário (se ainda não o fez) para garantir que a primeira parte, que recupera a imagem da URL, funcione corretamente. Após a solicitação-resposta, tente direcioná-la para um servidor SFTP para salvar o arquivo de imagem. Em seguida, faça o download do arquivo do SFTP e verifique se há alguma corrupção. Compare também com o arquivo original (baixado pelo navegador) em nível de bytes.

Em relação ao comprimento do conteúdo, não tenho certeza se há uma maneira de anulá-lo. Vou tentar pesquisar mais sobre isso e informá-lo se encontrar algo.

Saudações

Eng Swee

hex.png
Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?