...
...
...
Informaçõeswarning | ||
---|---|---|
| ||
No padrão REST/JSON, a indicação do tipo de operação - upsert ou delete - originalmente indicada na tag Event do padrão SOAP/XML, estará vinculada ao método HTTP utilizado na requisição. Mais informações serão prestadas na seção Interface deste documento. | ||
| ||
A tag Identification, subordinada à tag BusinessEvent, não será contemplada no formato REST/JSON. Essa tag | ||
Aviso | ||
| ||
A tag Identification, subordinada à tag BusinessEvent, não será contemplada no formato REST/JSON. Essa tag foi sendo substituída ao longo do tempo pelos InternalIDs do corpo das mensagens. Ao migrar um adapter para utilizar o novo formato, qualquer processamento baseado na tag Identification deve ser revisto. |
...
Bloco de código | ||
---|---|---|
| ||
{ "Header" : { "UUID" : "d6bbfa63-ca27-e2ac-0b14-101970f59a5b", "Type" : "BusinessMessage", "SubType" : "event", "TransactionEvent" : "CostCenterupsert", "VersionTransaction" : "2.000CostCenter", "Version" : "2.000", "SourceApplication": "P1299", "ProductName" : "PROTHEUS", "ProductVersion" : "12.1.17", "CompanyId" : "99", "BranchId" : "01", "GeneratedOn" : "2017-11-14T11:47:00-03:00", "DeliveryType" : "async", }, "Content" : { "CompanyId" : "99", "BranchId" : "01", "CompanyInternalId" : "99", "Code" : "ABC001", "InternalId" : "99|ABC001", "RegisterSituation" : "Active", "Name" : "Centro de Custo ABC001", "ShortCode" : "ABC001", "SPED" : true, "Class" : 2 } } |
...
Bloco de código | ||
---|---|---|
| ||
{ "Header" : { "UUID" : "a1b2c3d4-e5f6-g7h8-i9j0-k1l2m3n4o5p6", "Type" : "Response", "SubType" : "event", "Transaction" : "CostCenter", "Version" : "2.000", "SourceApplication" : "LGX12", "ProductName" : "LOGIX", "ProductVersion" : "12.1.15", "GeneratedOn" : "2017-11-14T11:47:15-03:00", "DeliveryType": "async" }, "Content" : { "ReceivedMessage" : { "UUID" : "d6bbfa63-ca27-e2ac-0b14-101970f59a5b", "SentBy" : "P1299", "Event" : "upsert" }, "ProcessingInformation" : { "ProcessedOn" : "2017-11-14T11:47:15-03:00", "Status" : "Ok" }, "ReturnContent" : { "ListOfInternalID" : [ { "Name" : "CostCenter", "Origin" : "99|ABC001", "Destination" : "10|1000" }, { "Name" : "Company", "Origin" : "99", "Destination" : "10" } ] } } } |
Para mensagem de Resposta Assíncronas o método do envio deve ser POST, pois esta sendo trafegada a resposta, independente da operação original. Para obter o processo da mensagem original pode se acessar a propriedade Content.ReceivedMessage.Event.
O padrão REST/JSON fornece também um modelo para lote de mensagens, onde as mensagens são agrupadas em um array JSON, de nome items.
Bloco de código | ||
---|---|---|
| ||
{ "Items" : [ { "Header" : { "UUID" : "", "Type" : "", "SubType" : "", "TransactionEvent" : "customerVendor", "VersionTransaction" : "2.001customerVendor", "SourceApplicationVersion" : ""2.001", "SourceApplication": "", "ProductName" : "", "ProductVersion" : "", "GeneratedOn" : "", "DeliveryType" : "async", }, "Content" : { "Atributo1" : "", "Atributo2" : "", ... "AtributoN" : "" } },{ "Header" : { "UUID" : "", ... "Transaction" : "item", "Version" : "3.001", ... "DeliveryType" : "async" }, "Content" : { "Atributo1" : "", "Atributo2" : "", ... "AtributoN" : "" } } ] } |
...
Informações | ||
---|---|---|
| ||
Por definição, não serão aceitas mensagens com subtipo request no método DELETE. Apenas mensagens com subtipo event serão permitidas. Quando tal situação ocorre, será retornado, no mínimo, o código HTTP 405 (Method not allowed). |
Exemplos de utilização deste predicado podem ser encontrados nos links a seguir:
No período de migração das implementações em XML para JSON, será necessário que os formatos convivam simultaneamente e sejam interoperáveis.Isso implica que a modelagem de uma transação usando o padrão REST/JSON seja compatível com a modelagem usando o padrão SOAP/XML (orientações no tópico seguinte).
Assim que todos os ERPs forem capazes de trabalhar com a nova proposta, o formato XML e os endpoints SOAP poderão ser desativados.
Para permitir a utilização dos adapters atuais, sem que seja necessário convertê-los de imediato para o formato JSON, está disponível um conversor de XML para JSON e vice-versa, implementado no formato de DLL. Para mais informações, consulte a documentação correspondente.
Para apoiar na migração de adapters do formato XML para o formato JSON, foi desenvolvido o documento Equivalência entre formatos, o qual possui orientações importantes para este processo.
O desenho de uma transação, no formato REST/JSON, deve utilizar o formato Json Schema, Draft 4 ou superior, em substituição ao formato XML Schema (XSD) utilizado na implementação SOAP/XML. Para mais informações sobre como implementar um documento no formato Json Schema consulte a especificação própria do padrão.
Em nome da consistência entre os formatos, é necessário ter em mente o seguinte procedimento: ao desenvolver, por exemplo, um documento Json Schema (padrão REST/JSON) para a transação CostCenter, versão 2.000, deve-se verificar se já existe um documento XSD da referida transação (padrão SOAP/XML). Existindo o documento, todos os atributos que definem a tag BusinessContent devem estar presentes no tipo equivalente no documento Json Schema, para que o modelo seja considerado como sendo da transação CostCenter, versão 2.000.
Por outro lado, é possível que um documento Json Schema seja implementado sem que haja o correspondente em XSD. Neste caso, a modelagem deve ser elaborada considerando que a transação também pode vir a ser usada no futuro para integração server-to-server, e por isso, deve conter atributos que permitam o uso em tal contexto, mesmo que inicialmente a utilização seja no contexto client-to-server. Se isso for levado em consideração, não será necessário criar um documento XSD equivalente para a mesma transação e versão.
Para a documentação da transação no arquivo de definição OpenAPI, há regras para a mensagem e para os campos, conforme abaixo:
Conforme descrito no item Funcionamento deste documento, os atributos relativos ao InternalId devem ser modelados, independentemente do contexto de uso.
O exemplo a seguir mostra a modelagem da transação CostCenter, versão 2.000, usando o padrão Json Schema, considerando a obrigatoriedade da definição de InternalIds, mas não o seu uso. Ou seja, os campos de InternalId não são marcados como requeridos.
Informações |
---|
Este exemplo foi reduzido para destacar a definição do modelo de dados. Entretanto, um modelo completo deve incluir, entre outras coisas, a documentação da mensagem conforme indicado anteriormente. |
Informações | ||
---|---|---|
| ||
Diante do descrito até o momento, há duas formas de se indicar a operação de uma mensagem do tipo BusinessMessage: via métodos HTTP (POST e DELETE) e via atributo Event. Sempre que for possível determinar a operação pelos atributos do canal, esta será a informação prevalente, como é o caso do canal REST, onde os métodos HTTP provêm essa indicação. Neste caso, pode ocorrer sobre posição da informação no atributo Event da mensagem, se ele não for compatível com a indicação do canal. O atributo Event, dentro da mensagem, será considerado apenas nos casos onde o canal não fornecer a indicação da operação, como é o caso do canal AMQP. |
Exemplos de utilização deste predicado podem ser encontrados nos links a seguir:
No período de migração das implementações em XML para JSON, será necessário que os formatos convivam simultaneamente e sejam interoperáveis.Isso implica que a modelagem de uma transação usando o padrão REST/JSON seja compatível com a modelagem usando o padrão SOAP/XML (orientações no tópico seguinte).
Assim que todos os ERPs forem capazes de trabalhar com a nova proposta, o formato XML e os endpoints SOAP poderão ser desativados.
Para permitir a utilização dos adapters atuais, sem que seja necessário convertê-los de imediato para o formato JSON, está disponível um conversor de XML para JSON e vice-versa, implementado no formato de DLL. Para mais informações, consulte a documentação correspondente.
Para apoiar na migração de adapters do formato XML para o formato JSON, foi desenvolvido o documento Equivalência entre formatos, o qual possui orientações importantes para este processo.
O desenho de uma transação, no formato REST/JSON, deve utilizar o formato Json Schema, Draft 4 ou superior, em substituição ao formato XML Schema (XSD) utilizado na implementação SOAP/XML. Para mais informações sobre como implementar um documento no formato Json Schema consulte a especificação própria do padrão.
Em nome da consistência entre os formatos, é necessário ter em mente o seguinte procedimento: ao desenvolver, por exemplo, um documento Json Schema (padrão REST/JSON) para a transação CostCenter, versão 2.000, deve-se verificar se já existe um documento XSD da referida transação (padrão SOAP/XML). Existindo o documento, todos os atributos que definem a tag BusinessContent devem estar presentes no tipo equivalente no documento Json Schema, para que o modelo seja considerado como sendo da transação CostCenter, versão 2.000.
Por outro lado, é possível que um documento Json Schema seja implementado sem que haja o correspondente em XSD. Neste caso, a modelagem deve ser elaborada considerando que a transação também pode vir a ser usada no futuro para integração server-to-server, e por isso, deve conter atributos que permitam o uso em tal contexto, mesmo que inicialmente a utilização seja no contexto client-to-server. Se isso for levado em consideração, não será necessário criar um documento XSD equivalente para a mesma transação e versão.
Para a documentação da transação no arquivo de definição Json Schema, há regras para a mensagem e para os campos, conforme abaixo:
Conforme descrito no item Funcionamento deste documento, os atributos relativos ao InternalId devem ser modelados, independentemente do contexto de uso.
O exemplo a seguir mostra a modelagem da transação Branch, versão 2.001, usando o padrão Json Schema, considerando a obrigatoriedade da definição de InternalIds, mas não o seu uso. Ou seja, os campos de InternalId não são marcados como requeridos.
Informações |
---|
Este exemplo foi reduzido para destacar a definição do modelo de dados. Entretanto, um modelo completo deve incluir, entre outras coisas, a documentação da mensagem conforme indicado anteriormente. |
Bloco de código | ||
---|---|---|
| ||
{
"$schema": "https://raw.githubusercontent.com/totvs/ttalk-standard-message/master/jsonschema/schemas/events/branch_2_001.json#",
"info": {
"description": "Contrato de Mensagem Padronizada para a entidade filial (Branch) para produtos TOTVS",
"version": "2.001",
"title": "Branch",
"contact": {
"name": "T-Talk",
"url": "API.Totvs.com.br",
"email": "[email protected]"
},
"x-totvs": {
"transactionMessageDocumentation": {
"subType": "event",
"businessContentType": {
"type": "object",
"$ref": "#/definitions/BranchType"
},
"returnContentType": {
"type": "object",
"$ref | ||
Bloco de código | ||
| ||
{ "$schema": "https://raw.githubusercontent.com/totvs/ttalk-standard-message/master/jsonschema/schemas/events/branchListOfInternalId_21_001.json#", "info": { "description": "Contrato de Mensagem Padronizada para a entidade filial (Branch) para produtos TOTVS"000.json#/definitions/ReturnContentWithModelType" } }, "versionmessageDocumentation": "2.001",{ "titlename": "Branch", "contactdescription": {"Filial", "namesegment": "T-Talk"FrameWork" }, "urlproductInformation": [ { "API.Totvs.com.br "product" : "protheus", "emailcontact": "comiteintegracao@totvsProtheus_FW@totvs.com.br", }, "x-totvsdescription": { "Cadastro de Filial", "transactionMessageDocumentationadapter": {"apcfg230i.prw", "subTypehelpUrl": "event",link aqui" } ] } }, "businessContentTypedefinitions": { "typeBranchType": "object", { "$reftype": "#/definitions/BranchTypeobject", },"properties": { "returnContentTypeCompanyCode": { "type": "objectstring", "$refexample": "https://raw.githubusercontent.com/totvs/ttalk-standard-message/master/jsonschema/schemas/ListOfInternalId_1_000.json#/definitions/ReturnContentWithModelType" } }, "messageDocumentation": { D", "namedescription": "BranchCódigo da Empresa", "descriptionx-totvs": "Filial", [ { "segmentproduct": "FrameWorkprotheus", }, "productInformationField": { "XX8.XX8_CODIGO", "protheusRequired": {false, "contactType": "[email protected]Char", "descriptionlength": "Cadastro de Filial12", "adapteravialable": "apcfg230i.prw"true, "helpUrlcanUpdate": "link aqui"false } } } }, "definitions": { ] "BranchType": { "type": "object", "properties": { "CompanyCode}, "internalId": { "type "description": "stringInternalId da entidade", "example "type": "Dstring", "descriptionexample": "Código da Empresa01", "x-totvs": [ { "product": "protheus": {, "Field": "XX8.XX8_CODIGO", "Required": false, "Type": "Char", "length": "12100", "avialable": true, "canUpdate": false } }] }, "Description": { "type": "string", "example": "Filial São Paulo 1", "description": "Descrição", "x-totvs": [ { "protheusproduct": {"protheus", "Field": "XX8.XX8_NOME", "Required": false, "Type": "Char", "length": "100", "avialable": true, "canUpdate": false } }] }, "Code": { "type": "string", "example": "D SP 01", "description": "Filial/Codigo Unidade", "x-totvs": null}, }(...) }, }"required":["CompanyCode"] } } } |