Integrações

Páginas filhas
  • Integração entre o ERP Datasul e o serviço TOTVS Apps (Plataforma TechFin)

Versões comparadas

Versão antiga 1

changes.mady.by.user Raphael Soares

Gravado em

comparado com

Nova versão 90

changes.mady.by.user Raphael Soares

Gravado em

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

INTEGRAÇÃO DATASUL X TOTVS APPS

Contexto de negócio

A arquitetura da plataforma TechFin requer a ingestão recorrente de dados para a integração com demais softwares externos, entre eles o Datasul. Neste sentido, os softwares externos enviam os dados para uma área de preparação (staging), cujos dados serão posteriormente transformados e normalizados para estruturas predefinidas pelos aplicativos do TechFin. 

Para assegurar a eficiência e escalabilidade da integração, a extração dos dados no produto Datasul é realizada de forma parcial, isto é, são considerados apenas os dados afetados (modificados) em um dado intervalo de tempo.


Sistemas Envolvidos

Para que os dados do produto datasul Datasul sejam disponibilizados para os aplicativos do serviço Totvs TOTVS Apps, estão envolvidos:

  • Totvs TOTVS RAC;
  • Totvs TOTVS Apps;
  • Totvs TOTVS Carol.


Integração

A integração tem o objetivo de disponibilizar na área de staging do serviço TOTVS Carol os dados criados, modificados ou excluídos, de tabelas predefinidas e em um determinado periodo período de tempo, de tabelas predefinidas, para que 

permitir que o cliente com ERP Datasul realize o envio de pedidos de compra e programação de entrega para fornecedores via oferta do TOTVS Colaboração, ou caso o cliente usuário do ERP Datasul ter a função de fornecedor, realize o recebimento e implantação de pedidos de venda enviados via TOTVS Colaboração, e posteriormente envie o aviso de embarque das notas fiscais.

Explique o contexto de negócio ou do problema na qual esta integração estará inserida. Isto inclui o funcionamento da(s) ponta(s) envolvida(s).

Apresentar a integração como uma melhoria para o cenário ou como uma solução para o problema.

  • Premissas
    Gerais, do Vertical, do BackOffice e dos demais artefatos/sistemas envolvidos
    Premissas Gerais
    Premissas A
    Premissas B
  • Arquitetura (Tecnologia)

Escopo

Descreva, dado o contexto, qual o escopo de atuação da integração. Cite as áreas/perfis de usuários e funções impactadas. Se existe uma parte do contexto de negócio que a integração não tenta resolver, deixe explícito.

Defina exatamente o que a integração FAZ, o que ela NÃO FAZ e a sua finalidade.

[O conteúdo poderá estar disponível na ferramenta PMS – Painel de Gestão de Projetos, opção Plano do Projeto]

Como são os processos os que serão integrados, mas com uma visão geral e não só o ponto de integração caso contrário a homologação [ou outro que pegar o documento] não saberá do que se trata no sistema vertical, de forma sucinta, como funciona e o(s) ponto(s) de integração.

Citar a responsabilidade de cada produto.

Descrever com mais detalhes sobre o que será integrado (mas não ser especialista nas entidades/processos, pois suas particularidades serão descritas posteriormente) incluindo diagramas, prints, imagens, etc o que for interessante para auxiliar o entendimento.

Interessante aqui a inclusão de diagramas, imagens, lógicas, fluxo(s) do(s) processo(s) o que considerar interessante e agregador ao documento e ao escopo.

Pré-requisitos instalação/implantação/utilização

Relacione quais são os pré-requisitos (técnicos ou de negócio) para a integração. Este tópico não deve incluir informações da implantação normal do módulo, mas apenas informações específicas da integração. É como se este tópico já partisse do princípio que o módulo que será integrado já está normalmente instalado.

Entre os tópicos deste tópico podemos citar:

  • Versões mínimas de produtos.
  • Módulos ou programas que geram informações necessárias a integração. Muitas vezes a integração partirá de informações que somente são trabalhadas em um determinado programa ou processo, que deverá estar em uso no cliente.
  • Ferramentas que são necessárias a integração, como: EAI, ESB, servidor de WebService etc.
  • Aspectos legais nos quais as partes envolvidas na integração devem estar inseridas, caso as informações envolvidas sejam utilizadas para o cumprimento de alguma lei específica.
  • Requisitos de hardware ou Software, como servidores, link de internet, capacidade de armazenamento e memória, sistema operacional.

Datasul

Insira aqui as informações pertinentes a Datasul.

Logix

Insira aqui as informações pertinentes ao Logix.

Protheus

Insira aqui as informações pertinentes ao Protheus.

RM

Insira aqui as informações pertinentes ao RM.

Instalação/Atualização

Este tópico tem por objetivo orientar a instalação da integração, visando o seu funcionamento completo. Instalação de produtos ou ferramentas necessárias podem referenciar outros documentos existentes, desde que estejam disponíveis no repositório de documentação da TOTVS ou sejam enviados junto com o documento da integração em si. As informações mínimas necessárias para teste tópico são:

  • Procedimentos que devem ser observados quando um dos produtos for atualizado.
  • Configuração necessária que deve ser realizada em arquivos de configuração ou programas de parâmetros etc.
  • Arquivos diversos que devem ser mantidos em determinados locais para o funcionamento da integração, exemplo: xml, xsd.
  • Atualizações necessárias em banco de dados ou instruções para que elas sejam feitas.
  • Processos, módulos ou programas que precisam ser instalados ou atualizados. Deve ser definida a versão mínima necessária dos programas envolvidos.
  • Ferramentas, servidores ou serviços que precisam ser disponibilizados e configurados, o que pode gerar necessidade de novo hardware ou aumento de capacidade. Exemplo: serviço de WebService.
  • Instruções para habilitar a comunicação da ferramenta EAI entre as partes, quais rotas devem ser definidas ou como as transações devem ser habilitadas.

 

Observação: evite o uso de Prints de telas, facilitando, assim, o trabalho de tradução e versionamento deste documento.

Datasul

Insira aqui as informações pertinentes a Datasul.

Logix

Insira aqui as informações pertinentes ao Logix.

Protheus

Insira aqui as informações pertinentes ao Protheus.

RM

Insira aqui as informações pertinentes ao RM.

Controle de Versão

O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.

Todas as evoluções programadas deverão ser discutidas e aprovadas pelas marcas antes do início do desenvolvimento e somente serão desenvolvidas em caso de concordância das marcas e alinhamento com as diretivas definidas pelo Comitê de Integração TOTVS.

Suporte

O suporte aos recursos da Integração será de responsabilidade de todas as linhas, sendo assim as equipes de suporte dos produtos RM Conector e Backoffice Protheus estarão aptas a fazer a primeira análise e, quando necessário, repassar para a equipe mais adequada em cada caso.

Observação: Este modelo de suporte está sendo revisado pela TOTVS.

Transações/Entidades/Mensagens únicas

Apresente quais as transações/entidades que são trocadas e quem envia a informação para quem. Pode (e recomenda-se) ter um diagrama, uma tabela ou afins que apresente este fluxo.

Relacione quais são as mensagem únicas (TOTVSMessage) utilizadas e qual o seu relacionamento com as entidades já existentes do ERPs envolvidos.

Exemplos:

 

 Image Removed

Image Removed

Método

ID

Descrição

Origem

Destino

XSD (versões podem variar)

Cadastros

01

Cliente/Fornecedor

RM

Protheus

CustomerVendor_1_000.xsd

02

Moeda

RM

Protheus

Currency_1_000.xsd

03

Unidade de Medida

RM

Protheus

UnitOfMeasure_1_000.xsd

04

Produto

RM

Protheus

Item_?_000.xsd

05

Centro de Custo

RM

Protheus

CostCenter_1_000.xsd

06

Ativos

RM

Protheus

NOVA, Ativo fixo

07

Funcionários

RM

Protheus

Employee_1_000.xsd

08

Projeto

RM

Protheus

Project_1_000.xsd

09

Obra

RM

Protheus

SubProject_1_000.xsd

10

Tarefa

RM

Protheus

TaskProject_1_000.xsd

11

Meio de Pagamento

RM

Protheus

?????.xsd

12

Condições de pagamento

RM

Protheus

PaymentCondition_1_000.xsd

13

Coligada*
* implementado, mas o Protheus não vai enviar, estamos avaliando alternativa para preencher o de/para

RM

Protheus

Company_1_000.xsd

14

Filial*
* implementado, mas o Protheus não vai enviar, estamos avaliando alternativa para preencher o de/para

RM

Protheus

Branch_2_000.xsd

Processos

15

Solicitações (compras/armazém)

Protheus

RM

Request_1_000.xsd

16

Cancelar movimento (solicitação, OS, etc)

Protheus

RM

CancelRequest_1_000.xsd

17

Cancelar movimento (solicitação, OS, etc)

RM

Protheus

CancelRequest_1_000.xsd

18

Baixa de estoque

Protheus

RM

Request_1_000.xsd

19

Baixa de estoque

RM

Protheus

Request_1_000.xsd

20

Consulta Saldo

Protheus

RM

21

Apropriação de custos

Request _1_000.xsd

22

Geração de OS

23

Consulta de OS

24

Ampliação patrimonial

Fluxo das Informações

 

Para cada fluxo de informação descreva, se necessário, alterações de comportamento que o respectivo produto irá sofrer. Por exemplo: quando o Logix recebe o PEDIDO de OUTRO ERP, este pedido não poderá ser alterado no Logix.

Liste quais as entidades integradas e como é o mapeamento entre as diferentes estruturas. Por exemplo: Classe no sistema A vira categoria no sistema B, o campo X é refletido no campo Y etc.

Liste quais transações/operações a integração fará com as entidades relacionadas. Exemplo: Insert de PEDIDO, Insert, update de ITEM, buscar saldo em estoque do ITEM no dia X ou buscar dados do FUNCIONÁRIO.

Cadastros

Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.

Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos

Em seguida faça uma descrição para cada um dos fluxos para cada entidade

 

<Transação/Entidade>

Identificador da Mensagem: <mensagem>

Versão: <versão>

Módulo <marca 1>: <BackOffice – Gestão xxxxxxx>

Módulo <marca 2>: <SIGAXXX>

Tipo de Envio: <Assíncrona/Síncrona>

Mensagem Padrão

PROTHEUS

RM

Tabela

Campo

Tabela

Campo

Code

CTO990

CTO_SIMB

GMOEDA

SIMBOLO *

Description

CTO990

CTO_DESC

GMOEDA

DESCRICAO

Symbol

CTO990

CTO_SIMB

GMOEDA

SIMBOLO

Notas:

Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela

A seguir descrever as variações, particularidades da mensagem e processos (integração) de acordo com cada marca

Limitações/Restrições

Descreva limitações e restrições para a integração que está sendo descrita.

Processos

Descreva características gerais do fluxo de informações e que serão comuns para este tipo de entidade. Características particulares para cada entidade deverão ser citadas em tópicos específicos de cada entidade.

Sempre que existir (a sugestão é sempre criar) e for agregador ao documento acrescentar aqui os diagramas/imagens ou até mesmo colocar tais diagramas diretamente na especificação dos processos

Em seguida faça uma descrição para cada um dos fluxos para cada entidade

 

<Transação/Processo>

Tipo de Fluxo: Protheus -> RM

Mensagem: Request_1_000

Versão: 1.000

Descrição de todo o comportamento e funcionamento do processo. Breve contexto, origem, regras, integração (geração da mensagem, envio, recebimento no destino), o quê supostamente irá ocorrer no destino, retorno, impacto, consequências, o que foi afetado, como conferir, validar, etc o retorno.

Acrescentar um diagrama do processo.

A seguir descrever as variações, particularidades da mensagem e processos (desta integração) de acordo com cada marca

Notas:

Observações sobre comportamento desta mensagem ou dos processos envolvidos nela/para ela

Limitações/Restrições

Descreva limitações e restrições para a integração que está sendo descrita. 

que as aplicações do serviço TOTVS Apps possam fazer uso destas informações . Entre os aplicativos do serviço TOTVS Apps estão o TOTVS Antecipa, o TOTVS Mais Negócios e o TOTVS Consignado.

Os dados que estão indisponíveis no ERP, dados excluídos, serão identificados na área de staging pelo campo active que indicará o valor false.

Os dados das tabelas enviados para o serviço Carol(CDS) serão enviados compactados. Para isso o produto fará uso do Gzip, que atende as especificações da RFC 1952 conforme a especificação da Carol.


Escopo

Esta integração disponibiliza dados das tabelas, indicadas pelo serviço TOTVS Apps, no serviço TOTVS Carol (CDS). Os dados são disponibilizados na área de staging para que possam ser normalizados e, por fim, utilizados pelos aplicativos. 

Image Added


Pré-requisitos instalação/implantação/utilização

Pré-requisitos (técnicos ou de negócio) para o funcionamento da integração: 

  • Progress Openedge na versão 11.7.5 ou superior;
  • Disponibilizar as seguintes bibliotecas do Progress Openedge 11.7.5 no início do propath:
    • <diretorio_instalação_progress>\gui\OpenEdge.BusinessLogic.pl;
    • <diretorio_instalação_progress>\gui\OpenEdge.Core.pl;
    • <diretorio_instalação_progress>\gui\OpenEdge.ServerAdmin.pl;
    • <diretorio_instalação_progress>\gui\netlib\OpenEdge.Net.pl.
  • Datasul 12.1.29 ou superior;
  • Dados de acesso e certificados dos serviços - DS - TEC - Aplicação de certificados no Progress:
    • TOTVS Rac;
    • TOTVS Apps;
    • TOTVS Carol.
  • Instalação do programa Gzip - Caso o sistema operacional onde será executado o RPW não seja windows.

Para a validação dos pré-requisitos e realização das configurações é possível utilizar o programa Assistente de configuração para integração com Totvs Apps.

Datasul

Configurações

As configurações necessárias para a integração são:

  • Parâmetros de Integração;
  • Parâmetros de Jornalização.

Nos parâmetros de integração serão informados os dados de autenticação e sincronização de informações e nos parâmetros de jornalização, a forma como os dados afetados serão identificados para que sejam enviados para o serviço Totvs Carol.

Parâmetros de integração

No Tomcat, nas propriedades do sistema, localize as Propriedades de integrações Totvs e informe os dados conforme orientação do manual.

Parâmetros de Jornalização

No Tomcat, nas propriedades do sistema, localize as Propriedades de Jornalização e informe os dados conforme orientação do manual.

Sincronização de dados Datasul x Totvs Apps

A integração dos dados se dará por meio da execução da tarefa AU0109 - Sincronização de Dados Datasul x Totvs Apps.

Informações
titleInformativo para ambiente que faz o uso do CDC

Sempre será executada automaticamente o processo de Geração de Policy CDC após este processo é realizado o processo de sincronização de dados. 

Release 12.1.2307.3 e superiores.

Expandir
titleCustomização dos dados antes da sincronização

É possível incluir, alterar ou remover informações do JSON do TableSchema ou TableData antes que ele seja sincronizado com a Carol, para isso deverão ser seguidos os passos abaixo:

  1. Criar um programa no diretório carol/<nome_logico_banco> com o nome <nome_tabela>_data.p. Exemplo: carol/emsfnd/usuar_mestre_data.p;
  2. O programa deverá estar preparado para receber um parâmetro de entrada do tipo Progress.Json.ObjectModel.JsonObject e para retornar um parâmetro do tipo Progress.Json.ObjectModel.JsonConstruct;
  3. No JSON de entrada serão enviadas as informações de dataType, dbName, tableName, company e data, conforme exemplo abaixo:
    1. Bloco de código
      languagejs
      themeRDark
      titleJSON Entrada
      {"dataType": "TableSchema" ou "TableData",
 "dbName": "<nome_logico_banco>",
 "tableName": "<nome_tabela>",
 "company": Código da empresa que está sendo integrada,
 "data": JsonObject para o dataType TableSchema ou JsonArray para o dataType TableData
}
  4. Exemplo de programa customizado:
    1. Bloco de código
      languagedelphi
      themeRDark
      titlePrograma customizado
      USING Progress.Json.ObjectModel.JsonArray.
USING Progress.Json.ObjectModel.JsonConstruct.
USING Progress.Json.ObjectModel.JsonObject.

DEFINE INPUT  PARAMETER pInput  AS JsonObject    NO-UNDO.
DEFINE OUTPUT PARAMETER pOutput AS JsonConstruct NO-UNDO.
                   
IF pInput:GetCharacter("dataType") = "TableData" THEN
    RUN customTableData IN THIS-PROCEDURE.
ELSE
    RUN customTableSchema IN THIS-PROCEDURE.
    
PROCEDURE customTableData PRIVATE:
    DEFINE VARIABLE oTableData AS JsonArray  NO-UNDO.

    ASSIGN pOutput    = NEW JsonArray()
           oTableData = pInput:getJsonArray("data").
           
    /*
       REALIZAR AS MANIPULAÇÕES NECESSÁRIAS NO OBJETO oTableData
    */          
           
    ASSIGN pOutput = oTableData.

END PROCEDURE.

PROCEDURE customTableSchema PRIVATE:
    DEFINE VARIABLE oTableSchema AS JsonObject NO-UNDO.

    ASSIGN pOutput      = NEW JsonObject()
           oTableSchema = pInput:getJsonObject("data").
    /*
       REALIZAR AS MANIPULAÇÕES NECESSÁRIAS NO OBJETO oTableSchema
    */
    oTableSchema:ADD("testeAdd","deuCerto!!!").
    
    ASSIGN pOutput = oTableSchema.

END PROCEDURE.
  5. Foram inseridos logs no programa para facilitar a identificação de possíveis erros. Para isso foi criado o tipo de log CAROLSYNC, conforme exemplo abaixo:
    1. Bloco de código
      languagetext
      themeRDark
      titleCAROLSYNC
      	Line 24043: [21/04/01@11:46:08.973-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableData Begin: 01/04/2021 - 11:46:08
	Line 24046: [21/04/01@11:46:08.973-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableData Params -> codBaseDados: emsfnd tableName: configur_propried dateFrom 01/04/2021 00:37:23,556-03:00 dateTo 01/04/2021 11:46:08,773-03:00
	Line 24050: [21/04/01@11:46:08.974-0300] P-005856 T-012048 1 4GL CAROLSYNC      getTableSchema Begin: 01/04/2021 - 11:46:08
	Line 24053: [21/04/01@11:46:08.974-0300] P-005856 T-012048 1 4GL CAROLSYNC      getTableSchema Params -> tableName: configur_propried
	Line 24078: [21/04/01@11:46:08.981-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData Begin: 01/04/2021 - 11:46:08
	Line 24081: [21/04/01@11:46:08.988-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData Input Data: c:\temp\/input_TableSchema_emsfnd_configur_propried.json
	Line 24087: [21/04/01@11:46:08.988-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData oParams: {"dataType":"TableSchema","dbName":"emsfnd","tableName":"configur_propried"}
	Line 24090: [21/04/01@11:46:08.989-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData customProgram Begin: 01/04/2021 - 11:46:08
	Line 24099: [21/04/01@11:46:08.992-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData customProgram End: 01/04/2021 - 11:46:08
	Line 24102: [21/04/01@11:46:08.994-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData Output Data: c:\temp\/output_TableSchema_emsfnd_configur_propried.json
	Line 24107: [21/04/01@11:46:08.995-0300] P-005856 T-012048 1 4GL CAROLSYNC      getTableSchema End: 01/04/2021 - 11:46:08
	Line 24112: [21/04/01@11:46:08.996-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableSchema Begin: 01/04/2021 - 11:46:08
	Line 24115: [21/04/01@11:46:08.996-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableSchema Params -> tableName: configur_propried syncMethod: PUT
	Line 24120: [21/04/01@11:46:08.997-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableSchema tableSchema: {"mdmStagingMapping":{"properties":{"cod_agrpdor":{"type":"character"},"cod_contexto_propried":{"type":"character"},"cod_livre_1":{"type":"character"},"cod_livre_2":{"type":"character"},"cod_propried":{"type":"character"},"dat_livre_1":{"type":"date"},"dat_livre_2":{"type":"date"},"des_propried":{"type":"character"},"fwk_last_modif":{"type":"datetime-tz"},"log_livre_1":{"type":"logical"},"log_livre_2":{"type":"logical"},"num_livre_1":{"type":"integer"},"num_livre_2":{"type":"integer"},"val_
	Line 24121: [21/04/01@11:46:08.997-0300] P-005856 T-012048 1 4GL CAROLSYNC      livre_1":{"type":"decimal"},"val_livre_2":{"type":"decimal"}}},"mdmCrosswalkTemplate":{"mdmCrossreference":{"cnfgrprp_id":["cod_propried","cod_agrpdor"]}},"testeCleber":"deuCerto!!!"}
	Line 24125: [21/04/01@11:46:08.998-0300] P-005856 T-012048 1 4GL CAROLSYNC      getHttpClient Begin: 01/04/2021 - 11:46:08
	Line 24128: [21/04/01@11:46:08.998-0300] P-005856 T-012048 1 4GL CAROLSYNC      getHttpClient Params -> path: /api/v2/staging/tables/&1/schema?connectorId=&2 tableName: configur_propried
	Line 24202: [21/04/01@11:46:09.006-0300] P-005856 T-012048 1 4GL CAROLSYNC      getHttpClient End: 01/04/2021 - 11:46:09
	Line 24682: [21/04/01@11:46:09.058-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableSchema PutHTTPRequest Begin: 01/04/2021 - 11:46:09
	Line 32759: [21/04/01@11:46:11.832-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableSchema PutHTTPRequest End: 01/04/2021 - 11:46:11
	Line 32762: [21/04/01@11:46:11.834-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableSchema End: 01/04/2021 - 11:46:11
	Line 33016: [21/04/01@11:46:11.848-0300] P-005856 T-012048 1 4GL CAROLSYNC      getHttpClient Begin: 01/04/2021 - 11:46:11
	Line 33019: [21/04/01@11:46:11.849-0300] P-005856 T-012048 1 4GL CAROLSYNC      getHttpClient Params -> path: /api/v2/staging/tables/&1?connectorId=&2&&returnData=false tableName: configur_propried
	Line 33100: [21/04/01@11:46:11.861-0300] P-005856 T-012048 1 4GL CAROLSYNC      getHttpClient End: 01/04/2021 - 11:46:11
	Line 33581: [21/04/01@11:46:11.946-0300] P-005856 T-012048 1 4GL CAROLSYNC      getDataRequest Begin: 01/04/2021 - 11:46:11
	Line 33584: [21/04/01@11:46:11.946-0300] P-005856 T-012048 1 4GL CAROLSYNC      getTableSchema Params -> codBaseDados: emsfnd tableName: configur_propried dateFrom: 01/04/2021 00:37:23,556-03:00 dateTo: 01/04/2021 11:46:08,773-03:00
	Line 33600: [21/04/01@11:46:12.114-0300] P-005856 T-012048 1 4GL CAROLSYNC      getDataRequest End: 01/04/2021 - 11:46:12
	Line 33624: [21/04/01@11:46:12.119-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData Begin: 01/04/2021 - 11:46:12
	Line 33627: [21/04/01@11:46:12.126-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData Input Data: c:\temp\/input_TableData_emsfnd_configur_propried.json
	Line 33633: [21/04/01@11:46:12.127-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData oParams: {"dataType":"TableData","dbName":"emsfnd","tableName":"configur_propried"}
	Line 33636: [21/04/01@11:46:12.128-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData customProgram Begin: 01/04/2021 - 11:46:12
	Line 33645: [21/04/01@11:46:12.130-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData customProgram End: 01/04/2021 - 11:46:12
	Line 33648: [21/04/01@11:46:12.133-0300] P-005856 T-012048 1 4GL CAROLSYNC      customData Output Data: c:\temp\/output_TableData_emsfnd_configur_propried.json
	Line 33653: [21/04/01@11:46:12.135-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableData PostHTTPRequest Begin: 01/04/2021 - 11:46:12
	Line 41725: [21/04/01@11:46:14.423-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableData PostHTTPRequest End: 01/04/2021 - 11:46:14
	Line 41728: [21/04/01@11:46:14.423-0300] P-005856 T-012048 1 4GL CAROLSYNC      syncTableData End: 01/04/2021 - 11:46:14
    2. Quando o nível do log estiver configurado para DEBUG (logginglevel 4 (Extended)), serão exportados os JSONs que foram enviados e recebidos do programa de customização. Para isso, será utilizado o diretório temporário para salvar os arquivos, que serão detalhados abaixo. No log CAROLSYNC será mostrado o nome do caminho completo onde foram salvas as informações.
      1. input_TableSchema_<nome_logico_banco>_<nome_tabela>.json: JSON de entrada com as informações do TableSchema. Exemplo de nome: input_TableSchema_emsfnd_usuar_mestre.json.
      2. input_TableData_<nome_logico_banco>_<nome_tabela>.json: JSON de entrada com as informações do TableData. Exemplo de nome: input_TableData_emsfnd_usuar_mestre.json.
      3. output_TableSchema_<nome_logico_banco>_<nome_tabela>.json: JSON de saída do programa customizado com as informações do TableSchema. Exemplo de nome: output_TableSchema_emsfnd_usuar_mestre.json.
      4. output_TableData_<nome_logico_banco>_<nome_tabela>.json: JSON de saída do programa customizado com as informações do TableData. Exemplo de nome: output_TableDataema_emsfnd_usuar_mestre.json.

Instalação/Atualização

Quando houver atualização do produto Datasul deve-se atentar para as seguintes necessidades:


Controle de Versão

O grupo TOTVS, representado por suas marcas, irá administrar as demandas de evolução dos layouts e demais ajustes, acordando junto aos solicitantes o prazo de liberação de release.

Todas as evoluções programadas deverão ser discutidas e aprovadas pelas marcas antes do início do desenvolvimento e somente serão desenvolvidas em caso de concordância das marcas e alinhamento com as diretivas definidas pelo Comitê de Integração TOTVS.

Endereços acessados

Durante a execução dos programas relacionados a integração, alguns endereços envolvidos são requisitados e para o funcionamento correto, estes endereços devem estar liberados para acesso. 

Os endereços utilizados são:

Checklist de suporte da aplicação

Instalação/Configuração

  • Verifique se o serviço Totvs RAC está disponível;
  • Verifique se o certificado do serviço Totvs RAC está instalado na pasta do progress;
  • Verifique as configurações de integração com o serviço Totvs RAC;
  • Verifique se o serviço Totvs Apps está disponível;
  • Verifique se o certificado do serviço Totvs Apps está instalado na pasta do progress;
  • Verifique as configurações de integração com o serviço Totvs Apps;
  • Verifique se o serviço Totvs Carol está disponível;
  • Verifique se o certificado do serviço Totvs Carol está instalado na pasta do progress;
  • Verifique as configurações de integração com o serviço Totvs Carol;
  • Verifique as configurações de jornalização;
  • Verifique as configurações de bancos do Audit Trail;
  • Verifique se as triggers ou policies foram criadas;
  • Verifique a agenda de execução

Limitações / Restrições Gerais

Descreva limitações e restrições para cada fluxo descrito no tópico anterior. Exemplo:

  • ERP1 envia ITEM cadastrado para o ERP2

ERP1 somente enviará o ITEM se este estiver em uma das famílias cadastradas no parâmetro FAMILIA_INTEGRACAO.

Se o tipo de valorização do estoque for FIFO.

  • ERP2 envia PEDIDO cadastrado para o ERP1

O pedido recebido no ERP1 vindo do ERP2 estará bloqueado para alteração.

 

Como fazer (opcional)

Descreva os passos que viabilizem a integração.

Exemplo:

Os passos para viabilizar a integração são:

  • No Logix ou no Protheus efetue o cadastro das seguintes informações: Clientes, fornecedores, transportadores, cidades, cotação de moeda e unidades de medida.
  • No Logix cadastrar um novo depositante e efetuar toda a parametrização necessária para a operação de WMS.
  • No Logix cadastrar um novo produto que seja controlado pelo WMS, para o depositante cadastrado anteriormente.
  • No Logix efetuar um processo de recebimento para o produto cadastrado anteriormente, utilizando uma nota fiscal provisória (tipo “A”).
  • No Protheus consultar a nota fiscal de recebimento que foi registrada no Logix, validando as informações recebidas.
  • No Logix efetuar um processamento de regularização fiscal, efetuando a cobertura dos produtos recebidos anteriormente.
  • No Protheus verificar se foi efetuado corretamente o relacionamento entre os dois documentos.
  • No Logix efetuar um processo de expedição para o novo produto cadastrado, até o momento do envio da mensagem de integração de pedido de venda.
  • No Protheus efetuar o faturamento do pedido de venda recebido.
  • No Protheus verificar se a nota fiscal gerada contém todas as informações necessárias para o segmento de operador logístico (armazém geral).
  • No Protheus efetuar a escrituração fiscal das notas fiscais, verificando se as regras da legislação deste segmento foram respeitadas.
  • No Logix é possível consultar o número do pedido de venda gerado para as notas fiscais de retorno simbólico e conta/ordem no programa WMS6333 (Consulta de Documentos). Para os processos de faturamento de serviço o número do pedido está disponível no programa WMS6411 (Movimentos a Faturar).

 

Situações comuns (opcional)

Descreva situações problemáticas comuns que podem ocorrer durante o funcionamento da integração e como solucioná-los. Neste ponto também é importante dar instruções de como reconhecer e investigar problemas que podem vir a ocorrer durante a integração. Se houver, apresente tabelas de códigos e descrições de erros que a integração poderá apresentar.

Este tópico possivelmente será alimentado com as experiências durante o desenvolvimento da integração e poderá ser realimentado durante o uso da integração no cliente.

Exemplo 1:

Tratamento de erros de integração (Produto A)

Erro

Mensagem

Solução

Código do erro

Mensagem exibida

Ação a ser tomada para resolução do erro.

Tratamento de erros de integração (Produto B)

Erro

Mensagem

Solução

Código do erro

Mensagem exibida

Ação a ser tomada para resolução do erro.

 

Exemplo 2:

Quando uma mensagem é enviada do Logix para o Protheus, podem ocorrer situações em que o WebService não estará totalmente funcional. Nestes casos uma mensagem de erro genérica irá aparecer na tela:

Exemplo:

Erro ao enviar a mensagem de Cidade via Integração

Se o arquivo de log for analisado, poderemos ver a falha na comunicação com o sistema destino:

-------------------------------------------------------------------------------

WSCERR044 / Não foi possível POST : URL http://172.16.31.57:8011/ws/FWWSEAI.apw

ADVPL WSDL Client 1.080707 / tst on 20120315 08:49:51

-------------------------------------------------------------------------------

Para resolver este problema, verifique as configurações do sistema de destino, analisando o funcionamento do servidor utilizado para esta comunicação e a habilitação do endereço do WebService. 

Checklist de suporte da aplicação

Crie um check-list de verificação de alguns pontos importantes para o funcionamento e atendimento da integração.

Instalação/Configuração

Relacione itens de verificação para garantir que a integração está corretamente instalada e configurada. Isto não pode ser uma cópia do procedimento de instalação/configuração, mas verificações pontuais que podem remeter aos itens da instalação
  • .

Checklist de Verificações:

Relacione itens de verificações para que o atendente possa:

  • Identificar o funcionamento da integração;
  • Identificar a ocorrências de problemas;
  • Coletar evidências do mau funcionamento relatado pelo cliente;
  • Realizar possíveis ajustes na integração quanto à configuração ou negócio.
Anexos

  • Verifique se os pedidos de execução estão sendo criados;
  • Verifique se não há erros na execução do pedido;
  • Verifique o relatório au0109 gerado no spool do servidor RPW;
  • Verifique o clientlog da execução do servidor RPW.