"Como eu chamo o JD Edwards" é a pergunta que mais recebo de equipes que constroem qualquer coisa que toque o ERP de fora — um fluxo do Power Automate, um script Python para reconciliação noturna, um front-end React para a equipe do armazém. Em 2026, a resposta não é mais "escrever um wrapper BSFN customizado": é AISApplication Interface Services: o gateway REST fornecido com o JD Edwards EnterpriseOne que expõe serviços de formulário, dados e orquestração via HTTP. e RESTRepresentational State Transfer: o estilo arquitetural baseado em HTTP usado pelo AIS, no qual cada requisição é stateless e carrega sua própria autenticação., e a escolha que você faz entre form services, data services e orchestrations decide se a sua integração sobrevive à próxima Tools Release.
Este é o guia prático para integração JD Edwards AIS REST — como o ciclo de vida da chamada realmente funciona, quando escolher cada tipo de chamada, como a autenticação e os session tokens se comportam em produção, e os modos de falha que atingem integradores depois de seis meses.
Por que o AIS substituiu tudo o que veio antes
Antes do AIS, integrar com o JD Edwards significava escolher uma de três opções dolorosas: escrever um wrapper BSFNBusiness Function: código C compilado que roda dentro do kernel JDE Call Object e expõe a lógica de negócio JDE para chamadas internas. customizado e chamá-lo pelo protocolo proprietário JDENet, construir uma interface flat-file Z-file, ou usar a antiga camada XML Interop que ninguém gosta de tocar. As três acoplavam fortemente o sistema externo aos internals do JDE, e as três quebravam em upgrades de Tools Release aproximadamente a cada 18 meses.
O AIS, distribuído como servidor Java standalone desde o Tools 9.2, expõe três famílias de endpoints REST: form services que conduzem uma APPL como um usuário faria, data services que leem ou escrevem diretamente em tabelas e business views, e orchestration services que agrupam uma sequência de etapas em um endpoint estável. Cada um resolve um problema de integração diferente, e escolher o errado é a causa mais comum de integrações que funcionam em DV e desmoronam em PD.
O ganho não é apenas a modernidade do protocolo. O AIS fica fora do ciclo de build do path code: uma nova orchestration entra em produção sem server package, e o mesmo endpoint roda contra DV, PY e PD alterando uma única entrada de configuração. Para organizações que executam JDE multi-site, só isso já vale o custo de migração dos estilos de interop mais antigos.
O ciclo de vida da chamada AIS, passo a passo
Toda chamada AIS segue o mesmo caminho de cinco etapas, independentemente de você estar lendo inventário ou disparando uma sales order orchestration:
A primeira etapa é a requisição de token. Seu client faz POST para /jderest/v2/tokenrequest com username, password, environment e role. O servidor AIS valida contra a segurança JDE, abre uma sessão Call Object em seu nome e retorna um session token (`jasToken`) mais o bloco userInfo. Esse token é válido pelo timeout de sessão configurado — normalmente 30 minutos ocioso — e representa um slot real de kernel no enterprise server. Trate-o como caro: nunca solicite um novo por chamada.
A segunda etapa é o payload da chamada. Faça POST para /jderest/v2/formservice, /jderest/v2/dataservice, ou /jderest/v2/orchestrator/<name>. O body é JSON, a estrutura depende do tipo de chamada, e o session token vai no body, não em um header, para endpoints v2. O erro mais frequente de primeira viagem é enviar o token em Authorization: Bearer, que a API v2 ignora silenciosamente.
A terceira etapa é o roteamento AIS. O servidor valida o token, mapeia a requisição para um kernel Call Object e encaminha a chamada pelo runtime JDE padrão — o mesmo usado por sessões HTML Server. Daqui em diante, a chamada é indistinguível de uma transação conduzida por usuário: os mesmos record locks, as mesmas processing options, as mesmas event rules disparam.
A quarta etapa é a execução JDE. O kernel executa a cadeia de business functions, acessa o banco de dados via JDBNET e monta o resultado. É aqui que você gasta a maior parte do tempo de relógio — normalmente 100–800ms para uma única chamada form service em um ambiente saudável, mais tempo se a APPL subjacente tiver lógica de fetch pesada ou se você estiver atingindo uma tabela concorrida como F4211 durante o fechamento mensal.
A quinta etapa é a resposta JSON. O AIS envolve a saída do kernel em um envelope estável: form data, grid rows, errors, warnings e um session token atualizado. Sempre leia os arrays errors e warnings mesmo com HTTP 200 — o JDE retorna erros de negócio (inventário insuficiente, formato de data inválido) dentro de um body 200 OK, não como códigos de erro HTTP.
Escolhendo entre form, data e orchestration services
A maior decisão arquitetural em qualquer integração AIS é qual dos três tipos de chamada usar. Eles parecem intercambiáveis na primeira demonstração, mas absolutamente não são intercambiáveis em produção.
Form services conduzem uma APPL existente exatamente como um usuário faria. Você especifica o formulário (por exemplo P4210_W4210A), a ação (Find, Add, Update) e os valores dos campos. O AIS literalmente executa as event rules do formulário de ponta a ponta. A vantagem é que toda a validação, processing options e lógica de eventos que você construiu dentro da APPL rodam automaticamente. A desvantagem é que sua integração quebra no momento em que alguém muda o nome de um controle do formulário, reordena uma coluna do grid ou adiciona um campo obrigatório. Use form services para ports pontuais de interfaces legadas que já imitavam workflows de usuário, não para novas integrações.
Data services leem ou escrevem diretamente em uma tabela ou business view, contornando completamente a camada APPL. Eles são rápidos — normalmente 30–80ms por chamada — e ignoram event rules, o que é tanto um recurso quanto uma armadilha. Para integrações de reporting somente leitura, são perfeitos. Para escritas, são perigosos: um insert de data service em F4211 não dispara a cadeia de eventos do sales order, então seu NER customizado que mantém uma tabela customizada de compromissos nunca roda, e três semanas depois o financeiro pergunta por que os compromissos estão fora de sincronia.
Orchestrations são a escolha padrão para qualquer integração não trivial em 2026. Você as constrói no Orchestrator Studio, versiona como código e as expõe como endpoints REST nomeados. Uma orchestration pode agrupar uma chamada form service, uma lookup data service, uma notificação e uma etapa Groovy customizada em uma única unidade transacional. Quando a APPL subjacente muda, a orchestration absorve a mudança — o contrato do seu caller externo permanece estável. Toda nova integração deve partir de orchestration, a menos que haja um motivo específico para não fazer isso.
Autenticação, session tokens e o custo de errar
A autenticação AIS é simples depois que você entende que o session token representa uma sessão real, consumidora de recursos, no enterprise server. Cada token mantém aberto um slot de kernel Call Object. Se você construir um client que solicita um token novo em cada chamada e nunca faz logout, você vai esgotar o pool de kernels. Em um ambiente 9.2 típico com a configuração padrão de kernel, você tem entre 50 e 200 kernels Call Object concorrentes — queime todos eles e todo usuário JDE, incluindo web client, começará a ver erros "no available kernel".
O padrão correto é: adquirir um token por processo, reutilizá-lo durante a vida útil do trabalho e chamar /jderest/v2/tokenrequest/logout ao terminar. Para serviços long-running, atualize o token antes do idle timeout (normalmente 30 minutos) fazendo qualquer chamada barata. O AIS também suporta um padrão de sessão poolable, no qual várias tarefas curtas compartilham um token — apropriado quando sua integração é uma função serverless que pode rodar centenas de vezes por hora.
A integração OAuth 2.0 com AIS existe, mas não é almoço grátis. O AIS ainda precisa de um usuário JDE por trás de cada chamada — o OAuth leva seu usuário externo até o gateway AIS, mas então o AIS mapeia essa identidade para um usuário JDE por meio do mapeamento baseado em função definido no Server Manager. Se o mapeamento estiver errado, seu usuário autenticado via OAuth roda com a role JDE errada e falha na autorização ou, pior, tem sucesso com privilégios elevados. A tabela de mapeamento é o artefato de segurança mais negligenciado em implantações AIS.
Service accounts são a realidade prática para integrações system-to-system. Crie um usuário JDE dedicado (não uma conta pessoal) para cada sistema externo, limite sua role exatamente ao que esse sistema precisa e faça rotação da senha pelo Server Manager a cada 90 dias. Nunca compartilhe uma service account entre duas integrações — quando uma delas for comprometida ou gerar ruído de auditoria, você precisa desabilitar apenas aquela.
Estrutura do payload, tratamento de erros e o que o AIS não conta
O payload JSON das chamadas AIS é verboso. Uma chamada form service para P4210 com cinco valores de campo tem cerca de 1–2 KB de JSON; um fetch data service retornando 200 linhas de grid tem 50–150 KB. A maior parte do volume é metadata estrutural, não dados de negócio. Para integrações de alto volume, meça o tamanho real do payload contra sua capacidade de rede — um site remoto em uma WAN de 10 Mbps que executa 30 fetches de grid por segundo vai saturar o link muito antes de o servidor AIS sentir qualquer carga.
O tratamento de erros é onde a maioria das integrações AIS está silenciosamente quebrada. HTTP 200 não significa sucesso. Sempre analise os arrays warnings e errors no body da resposta. Um padrão típico: uma inclusão de sales order retorna 200 OK com array errors vazio, mas com array warnings não vazio contendo "Item not stocked at branch" — o pedido foi criado, mas com um status que exige revisão manual. Tratar 200 como sucesso e descartar o body perde esse sinal completamente. Da mesma forma, o AIS retorna HTTP 400 para requisições malformadas, mas HTTP 200 com errors preenchido para violações de regras de negócio. Ambos precisam ser tratados, em caminhos de código diferentes.
O envelope da resposta muda entre endpoints v1 e v2. A v1 (ainda viva em Tools Releases mais antigas) envolve dados de grid dentro de fs_FORMNAME.data.gridData.rowset; a v2 achata isso para formOutput e gridData. Misturar os dois no mesmo client é a maior fonte de bugs do tipo "funcionava ontem". Escolha uma versão explicitamente na configuração do seu client AIS e mantenha-a em todas as integrações no mesmo ambiente.
Tipos de campo merecem cuidado especial. O AIS retorna datas como JDE Julian (CYYDDD) ou ISO, dependendo do endpoint e das configurações do data dictionary do formulário. Campos numéricos podem voltar como strings se o data item subjacente tiver casas decimais — o JDE os armazena como inteiros e o decimal implícito vive no data dictionary, não no dado. Seu client deve reaplicar o posicionamento decimal do data dictionary, ou você reportará silenciosamente valores 100x ou 1000x errados.
Os erros que quebram integrações AIS em produção
O primeiro modo de falha é tratar o AIS como se fosse uma web API stateless. Ele tem estilo REST, mas o runtime JDE subjacente é profundamente stateful: locks, processing options em cache por sessão, caches em nível BSFN. Duas chamadas paralelas com o mesmo token podem colidir de maneiras que duas chamadas paralelas a um serviço REST stateless não podem. Para integrações concorrentes, use pool de tokens (um por worker) ou serialize chamadas por business key.
O segundo é ignorar a taxa com que o AIS encaminha chamadas para o kernel. O próprio servidor AIS pode aceitar milhares de requisições HTTP por segundo, mas cada chamada encaminhada consome um slot de kernel durante a transação JDE. Se sua integração envia 200 sales orders por segundo por meio de um form service que leva 600ms cada, você precisa de 120 kernels concorrentes só para essa integração — provavelmente mais do que todo o ambiente possui. Meça o throughput end-to-end contra a capacidade real de kernel, não contra a camada HTTP do AIS.
O terceiro é construir orchestrations que chamam form services internamente em vez de usar data services ou BSFNs customizados para as partes que não precisam de lógica APPL. Uma chamada form service dentro de uma orchestration carrega todo o overhead das event rules — mínimo de 300–500ms — mesmo quando tudo o que você precisava era uma leitura de 30ms. Para orchestrations que rodam milhares de vezes por hora, misturar corretamente os tipos de chamada é a diferença entre um tempo total de execução de 8 segundos e um de 80 segundos.
O quarto é deixar orchestrations sem versionamento. O Orchestrator Studio suporta versões por um motivo: depois que uma orchestration é consumida por um sistema externo, seu contrato de request e response faz parte da sua API. Editá-la em produção sem aumentar a versão é como quebrar todos os consumidores downstream ao mesmo tempo. Trate versões de orchestration como você trata assinaturas BSFN.
Se esse tipo de detalhe é o que você precisa para seu trabalho atual de integração, os artigos relacionados neste site cobrem patterns de Orchestrator Studio, medição de performance BSFN e otimizações do lado SQL que combinam com leituras AIS de alto volume. O portfólio de projetos mostra onde essas técnicas foram aplicadas a projetos reais de integração ERP.
