Histórico da Página

...

{
	"hasNext": false,
	"items": [{
		"name": "param1",
		"value": "1.01"
	},
	{
		"name": "param2",
		"value": "####"
	},
	{
		"name": "param3",
		"value": 30.5
	},
	{
		"name": "param4",
		"value": ""
	},
	{
		"name": "param5",
		"value": "2017-09-01T00:00:00"
	}]
}

Parâmetros de Adapters

• Mascara de produto - parametro de estoque
• Máscara de cliente fornecedor  - parâmetro de financeiro
• Status de projeto  - parâmetro de gestão de projetos
• MASCARA DE PRODUTO - PARAMETRO DE ESTOQUE
• MASCARA DE CLIENTE FORNECEDOR  - PARAMETRO DE FINANCEIRO
• STATUS DE PROJETO  - PARAMETRO DE GESTÃO DE PROJETOS

Questões a analisar

• Hoje o configurador so permite selecionar um pacote por vez.
• Como os desenvolvedores saberiam os adapters existentes ou pacotes, sem um fonte centralizador? Página no tdn?
• No JASON de metadados teremos a tag para bloquear a edição?
• JSON de configuração ficara no repositorio totvsmsg? se sim nem todos tem acesso. Se sim, em qual pasta?
• Versão da mensagem configurada conforme a versão dos produtos.
• Como configurar um parâmetro RM com base em uma configuração do Protheus?
  • Ex.: Para saber se devemos configurar o Produto como global devemos consultar no Protheus qual o compartilhamento do mesmo.
    • Para viabilizar este comportamento é necessário já possuir o caminho do URL do sistema de destino, talvez pre-configurando o par de Apps antes da configuração do pacote.
• Como será informado para as APIs de transaction qual o tipo de pacote (sou backoffice ou vertical?) e a versão do produto e da mensagem que será aplicada??
  • Isso será informado na URL? Esta solução não tem boa manutenção, tendo que alterar todos os JSons caso precise ser passado novo parametro e deverá passar queryparams no método POST.

...