B2B inbound - Emails estranhos

[Former Member]

Olá pessoal,

Encontrei um problema que pode ser comum à todos que recebem NFe e CTe por email dos seus fornecedores.

No nosso cenário, um adapter module lê os anexos do email que chegam na caixa postal de nfe e cte, e encaminha estes anexos pro processamento (ou descarta, se for lixo). Pra identificar o tipo de arquivo anexo e fazer a leitura de maneira adequada, a primeira coisa que faço é identificar o ContentType de cada anexo.

Ocorre que os emails de alguns fornecedores (menos de 5%) chegam com o ContentType = multipart/mixed;boundary="--Boundary3732.352941176470588745--", e não consigo descobrir o que é o xml, o que é o pdf e o que são os ícones da assinatura de email, pois todos os anexos tem esse mesmo ContentType. O filename no ContentDisposition é sempre "MailAttachement-x.bin", onde x varia de acordo com o sequencial do anexo no array de anexos.

O "normal" é que o ContentType seja algo como application/octet-stream;name="35120668404912000162550010001333481282122557.xml", application/octet-stream;name="35120668404912000162550010001333481282122557.pdf", application/pdf; name="2012454.pdf" ou qualquer coisa parecida.

Estou trabalhando nisso já há algumas horas. Se alguém já tinha identificado isso e encontrou uma solução, fico agradecido. Se não encontrou e quiser contribuir com a pesquisa, fique à vontade!

Um abraço!

Waldemar Roberti

[henrique_pinto · Accepted solution]

Possível solução tosca: vc dar forward dos emails para uma outra conta de email interna. Hopefully, esse forward converteria o header MIME original em um criado pelo seu mail server.  Boa sorte com a solução elegante.

[Former Member · Accepted solution]

Bom dia Henrique!

Orientei o faturamento pra fazer isso nos casos urgentes semana passada, funciona. O forward automático não funciona, mas abrindo no cliente de email e encaminhando resolve a brincadeira.

Implementei o plano B que eu tinha citado ontem, já está em produção. Foi mais fácil que eu imaginei, não ficou bonito mas vai funcionar pra esse caso.

Eu imaginei que teria problema na hora de tirar o lixo da mensagem MIME e decodificar o base64... a assinatura do XML da nota provavelmente não ia fechar (qualquer byte torto invalidaria a assinatura). Pra minha surpresa, fechou certinho! Já testei duzentos e cinquenta emails, redondo.

Ainda espero que o desenvolvedor do software corrija a barbeiragem no sistema que gera os emails, mas agora ele tem tempo pra arrumar e colocar em produção nos clientes dele sem a pressão do nosso go-live.

Um abraço!

Waldemar

[Former Member]

Para atualizar,

Identificamos que esta situação está acontecendo com vários fornecedores que utilizam o mesmo ERP de uma empresa aqui da região.

Aparentemente a aplicação deles que está criando o o email e anexando os arquivos está usando algum recurso específico que os clientes de email conseguem tratar, mas que não está contemplada na API que temos disponível pra usar no desenvolvimento de custom adapter modules (com.sap.aii.af.ra.ms.api.Payload). Estou tentando contato com os desenvolvedores deles. Tomara que não tenham usado uma DLL do outlook

Continuamos investigando.

[Former Member]

Pra atualizar,

Identificamos vários outros emails que usam o mesmo ContentType para o cabeçalho MIME e são lidos normalmente. O ContentType dos anexos fica sempre correto.

A diferença para os emails multipart/mixed que não são lidos é que estes tem uma boundary definida no cabeçalho e usada para o corpo do email, e uma nova boundary definida para cada anexo.

Continuamos investigando.

[former_member182114]

Bom dia Waldemar,

Desculpe a pergunta de leigo, teria como ler parte do conteúdo do arquivo para saber se contém as tags relativas a NFe? Digo, antes de fazer um parsing fazer um à moda antiga instr(xml,'protNFe') ou algo assim?

Atenciosamente, Fernando Da Ros

[Former Member]

Bom dia Fernando.

O problema é antes de conseguir o arquivo ainda.

Quando o email é lido pelo adapter engine, temos a mensagem principal, que conseguimos a partir do ModuleData

     Message mailMessage = (Message)inputModuleData.getPrincipalData();

E essa mensagem principal possui um array de anexos que lemos com o AttachmentIterator

     Iterator attachmentIterator = mailMessage.getAttachmentIterator();

Em cada passo do loop, temos como manipular um anexo

     while (attachmentIterator.hasNext()) {

          attachmentPayload = (Payload)attachmentIterator.next();

          processAttachment(attachmentPayload);

     }

Neste ponto, o attachmentPaylod já deveria ser um dos arquivos anexo (XML, PDF ou qualquer outro lixo). Dá pra verificar o conteúdo salvando o attachmentPayload no disco, ou debugando (xmbPayload/data/rep).

Ocorre que neste caso o attachmentPayload (aparentemente) ainda não foi extraído do pacote MIME e decodificado de base64. Então, no caso de um PDF, por exemplo, ele está assim

Quando deveria estar assim

Na primeira imagem, o que veio na lista de anexos é um pedaço da mensagem MIME, ainda não decodificada.

A diferença entre esses dois emails, até agora, é que o primeiro usa múltiplos Boundaries para separar os anexos na mensagem MIME (cada anexo tem um boundary diferente, e aparentemente o mail adapter do PI não consegue lidar com isso), enquando no segundo todos os anexos são separados por um único boundary, declarado no cabeçalho da mensagem MIME - e aí o mail adapter funciona certinho e decodifica a mensagem antes de colocar no attachmentIterator .

Estou tentando um plano B neste momento. Vou ler o conteúdo do attachmentPayload como binário, tentar identificar o início e o fim do conetúdo base64 (parece que o delimitador é CRLF), decodificar e gravar o arquivo. Vamos ver se vai ser simples assim...

[former_member182114]

Bom dia Waldemar,

Obrigado por me explicar.

Atenciosamente, Fernando Da Ros