Tornar o endpoint processQuery compatível com o manifesto de pipelines (data subscription na tenant unificada)
Description
Lista de parâmetro do endpoint `/api/v2/bigQuery/processQuery`
e do manifesto de pipelines:
Atributo | Manifesto | processQuery | Descrição |
---|---|---|---|
entityTemplateName | outputDataModelName | entityTemplateName | Nome do data model que terá os dados gravados |
deltaMinutes | overlapDeltaMinutes | deltaMinutes | Manifesto considera a ultima task, por comentários obtidos em issues o processQuery considera currentTimestamp ao invés da última task. |
saveBigQuery | saveToUnified | saveBigQuery | No unificado, o parâmetro para salvar no unificado significa saveUnified. Não temos parâmetro para não gravar no BQ da tenant cliente. |
clearBigQuery | clearBigQuery | Manifesto não possui esse recurso. | |
saveCds | saveToCds | saveCds | Unificado: indica se deve ser salvo no CDS da tenant cliente. |
clearCds | clearCds | Manifesto não possui esse recurso. | |
sendSubscriptions | sendToSubscriptions | sendSubscriptions | Unificado: indica se deve ser enviado para o Data Subscription da tenant cliente. |
clearRealtime | clearRealtime | Manifesto não possui esse recurso. Unificado não é compatível com esse recurso pois não permite o storage type RT. |
|
sendRealtime | saveToRealtime | sendRealtime | Unificado: indica se deve ser salvo no RT da tenant cliente. Unificado não é compatível com esse recurso pois não permite o storage type RT. |
useBatchNotification | useBatchNotification | useBatchNotification | |
checkExistingDataToProcess | checkExistingDataToProcess | checkExistingDataToProcess | |
carolAppName | Já está no contexto do Carol App. | carolAppName | |
pipelineName | pipelineName | pipelineName | |
fanOut | fanOut | ||
tempTableRetentionPeriod | tempTableRetentionPeriodDays | tempTableRetentionPeriod |
Sugestões:
- Criar uma tag de versão no manifesto de pipelines.
- Aplicar ajustes apenas se estiver estipulado v2.
- Sugestões para equalizar o comportamento, como é v2 podemos renomear atributos para deixar o mesmo nome.
Informações Adicionais
/api/v2/bigQuery/processQuery
em uso pelo Orchestrator, VSCode e outras implementações para processamento de dados.
Atributo | Manifesto | processQuery | Descrição |
---|---|---|---|
deltaMinutes (ajustes) | overlapDeltaMinutes | deltaMinutes | Manifesto considera a ultima task, por comentários obtidos em issues o processQuery considera currentTimestamp ao invés da última task. Ação: última task executada para o Data Model com sucesso ignorando tasks não executadas por conta da eficiência (tasks que tenham executado a pipeline SQL no BigQuery). Caso o processQuery não receba o parâmetro o nome do app ou o nome da pipeline deve-se subtrair o valor de deltaMinutes do currentTimestamp(). |
fanOut (ajustes) | fanOut | manifesto :: tenant unificada: valor true => efetua o envio dos dados para a tenant customer conforme demais parâmetros. manifesto :: tenant unificada: valor false => ignora o envio dos dados para as tenants customer (ignora os parâmetros save*). processQuery deve manter o comportamento atual, descrito nesta issue:
CAPL-4561: Endpoint processQuery should allow a parameter to specify if it should fanout...Done
|
|
sendRealtime | +sendRealtime+Customer | sendRealtime | processQuery :: sendRealtime: mesmo comportamento que o atual. manifesto :: +sendRealtime+Customer: grava os dados processados na camada RT da tenant cliente (apenas se fanOut está ligado). Mesmo comportamento que o atual. Tenant unificada não tem RT. |
clearRealtime | +clearRealtime+Customer | clearRealtime | processQuery :: clearRealtime: mesmo comportamento que o atual. manifesto :: +clearRealtime+Customer: limpa os dados na camada RT da tenant cliente (apenas se fanOut está ligado). Mesmo comportamento que o atual. Tenant unificada não tem RT. |
sendSubscriptions (ajustes) | sendSubscriptionsCustomer sendSubscriptionsUnified |
sendSubscriptions | processQuery :: sendSubscriptions: mesmo comportamento que o atual. manifesto :: sendSubscriptionsUnified: envia os dados para os data subscriptions ligado ao data model de output da tenant unificada. manifesto :: sendSubscriptionsCustomer: envia os dados para os data subscriptions ligado ao data model de output da tenant unificada (apenas se fanOut está ligado). |
clearSubscription (novo) | clearSubscriptionsCustomer clearSubscriptionsUnified |
clearSubscriptions | processQuery :: clearSubscriptions: limpa a fila de todas as subscriptions ligadas ao data model de output. manifesto :: clearSubscriptionsUnified: limpa todos a fila de todos os subscriptions ligado ao data model da tenant unificada. manifesto :: clearSubscriptionsCustomer: limpa a fila de todas as subscriptions ligadas ao data model de output. |
Endpoint atual com o recurso: {{`/api/v1/subscription/$
{dataSubscriptionId}/clear`}}|
saveBigQuery (ajustes) | saveBigQueryCustomer saveBigQueryUnified |
saveBigQuery | processQuery :: saveBigQuery: como ocorre hoje. manifesto :: saveBigQueryUnified: indica que será salvo na tenant unificada. manifesto :: saveBigQueryCustomer: indica que será salvo na tenant cliente, necessário que o fanOut esteja true. |
clearBigQuery (ajustes) | clearBigQueryCustomer clearBigQueryUnified |
clearBigQuery | processQuery :: clearBigQuery: como ocorre hoje. manifesto :: clearBigQueryUnified: indica que irá limpar os dados da tenant unificada. manifesto :: clearBigQueryCustomer: indica que será eliminado os dados na tenant cliente, necessário que o fanOut esteja true. |
saveCds (removido) | saveToCds | saveCds | Remover parâmetro. |
clearCds (removido) | clearCds | Remover parâmetro. |
PRDE - Story default text according to the team DoR (Definition of Ready)
01 - PERSON OF CONTACT (PERSON THAT CAN ANSWER QUESTIONS ABOUT THE PROBLEM): Robson Poffo
03 - GOAL (DESCRIBE THE PROPOSED SOLUTION)
- Padronizar as formas de processamento de dados para equalizar comportamentos e permitir que tenants unificadas tenham o recurso de Data Subscription (algo não disponível hoje).
04 - PROBLEM (WHAT'S THE CURRENT PROBLEM SCENARIO OR PAIN TO BE RESOLVED?):
- Tenants unificadas não podem ter Data Subscription registrado para sincronizar dados com sistemas externos.
10 - ACCEPTANCE CRITERIA:
- Se optarmos por migrar manifestos existentes:
- Plano de migração dos manifestos para mitigar impacto.
- Se optarmos pela nova versão do manifesto de pipelines:
- Permitir que a versão “original” do manifesto de pipelines funcione sem impactos (processamento de dados).
- Permitir Carol Apps com o novo manifesto de pipelines especificando atributos afim de suportar Data Subscription.
Activity
Show:
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
@MARCOS STUMPF ,
@Geny Isam Hamud Herrera , @André Pereira de Oliveira , @Cindy de Araujo Soares Moore , @Douglas Coimbra Lopes , @Lucas Noetzold , @Reinaldo Oliveira Machado Junior
Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/CAPL-6069#icft=CAPL-6069,https://totvsideia.atlassian.net/browse/PRDE-3798#icft=PRDE-3798,https://totvsideia.atlassian.net/browse/PRDE-3957#icft=PRDE-3957, conforme menções feitas em comentário editado.
@MARCOS STUMPF ,
@Geny Isam Hamud Herrera , @André Pereira de Oliveira , @Cindy de Araujo Soares Moore , @Douglas Coimbra Lopes , @Lucas Noetzold , @Reinaldo Oliveira Machado Junior
Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/PRDE-3957#icft=PRDE-3957, conforme menções feitas no comentário anterior.
Expectativas:
Tornar o endpoint processQuery compatível com o manifesto de pipelines - ACTIONS
Data subscription na tenant unificada - VALID
Ações feitas até o momento no card:
ACTION: deltaMinutes: Não foi implementado a mudança de comportamento esperado pelo card
ACTION: Ainda faltam alguns atributos serem padronizados em questão de nomenclatura, ex: outputDataModelName
VALIDAR: FanOut: Esse parametro irá controlar como “chave mestre” os valores
sendRealtimeCustomer → Renan validou que não está sendo controlado pelo FanOut
sendSubscriptionsCustomer
saveBigQueryCustomer
clearRealtimeCustomer
clearBigQueryCustomer → Vai ser implementado em outro card https://totvsideia.atlassian.net/browse/PRDE-3957
FanOut FALSE: Não vai nem olhar nenhum dos 3 parametros citados acima, sempre serão assumido FALSE para tudo;
FanOut TRUE: Vai olhar individualmente os valores de cada atributo
saveCds:
No endpoint v4 não existe/removido
ACTION: Manifesto v2 deve sempre assumir o valor FALSE mesmo que seja passado TRUE
ACTION: Endpoints v1/v2/v3 independente do valor passado será assumido FALSE
Foi implementado assim, porem PRODUTO confirmou que a expectativa é que nos endpoints antigos o valor do atributo fosse considerado para funcionalidade
clearCds:
No endpoint v4 não existe/removido
ACTION: Manifesto v2 deve sempre assumir o valor FALSE mesmo que seja passado TRUE
ACTION: Endpoints v1/v2/v3 independente do valor passado será assumido FALSE
Foi implementado assim, porem PRODUTO confirmou que a expectativa é que nos endpoints antigos o valor do atributo fosse considerado para funcionalidade
ACTION: Process all data: Nesse caso deve respeitar os valores que estão no Manifesto
ACTION: Quando usuario seleciona “Clean and process all Data” deveria ser assumido os valores abaixo INDEPENDENTE do que está no Manifesto:
clearBigQueryCustomer: TRUE → Vai ser implementado em outro card https://totvsideia.atlassian.net/browse/PRDE-3957
clearBigQueryUnified: TRUE
clearCds: TRUE
clearRealtimeCustomer: TRUE
Resultado da reunião de hoje com os participantes:
@Robson Thanael Poffo @MARCOS STUMPF @Lucas Noetzold @Renan Fernando Schroeder @Reinaldo Oliveira Machado Junior @Gabriel DAmore Marciano @Jonathan Willian Moraes @Moises Jose Soares Filho @Douglas Coimbra Lopes cc @Cindy de Araujo Soares Moore
Link do documento: https://www.notion.so/totvsideia/CAPL-6069-PRDE-3798-ca2811ba844a42e58d5dfd7716f41407?pvs=4
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi aprovado o PR.
Foi realizado o commit.
PR foi aprovado no Github.
PR foi aprovado no Github.
@MARCOS STUMPF ,
@Gabriel DAmore Marciano , @Geny Isam Hamud Herrera , @André Pereira de Oliveira , @Cindy de Araujo Soares Moore , @Douglas Coimbra Lopes , @Lucas Noetzold , @Reinaldo Oliveira Machado Junior
Este issue foi planejada para ser entregue até 2024-08-30. Você pode confirmar consultando o campo Due Date desta issue.
Data já planejadas para esta issue: 2024-08-30
Se o campo External Issue Link estiver preenchido com o link de uma issue válida no Jira Produção o cliente também será notificado no Jira Produção.
Card validado pelo time de QA. Pendente apenas o code review.
Mensagem enviada pelo Slack - platform-sre-qa-internal - Douglas Coimbra Lopes
> • Customer executa processQuery enviando savetoUnified True: Os dados do DM serao salvos na unified com a request vindo do customer?
>
Não, o manifesto é executado apenas na unificada. Temos algum processo que permite rodar no cliente o manifesto?
O processQuery não tem parametro saveUnified. Ok?
> • Customer executa processsQuery enviando subscriptionTrue para Unified: Tenant Unificada recebe os dados de subscription?
>
O processQuery não tem parametro para envio de Data Subscription para a unificada, correto?
> • Duvida: processQuery sendo reprocessado na customer, os parametros enviados para unified sao ignorados?
>
Eu fiquei na duvida pq o endpoint a principio não foi refatorado, foi criado uma nova versão do manifesto apenas (que roda apenas na unificada).
Mensagem enviada pelo Slack - suporte - Robson Poffo
Bom dia pessoal, uma duvida voltado a testes e cenarios esperados voltado ao processQuery na v2 do manifesto . cc
• Customer executa processQuery enviando savetoUnified True: Os dados do DM serao salvos na unified com a request vindo do customer?
• Customer executa processsQuery enviando subscriptionTrue para Unified: Tenant Unificada recebe os dados de subscription?
• Duvida: processQuery sendo reprocessado na customer, os parametros enviados para unified sao ignorados?
Mensagem editada no Slack - suporte - Douglas Coimbra Lopes
Bom dia pessoal, uma duvida voltado a testes e cenarios esperados voltado ao processQuery na v2 do manifesto . cc
• Customer executa processQuery enviando savetoUnified True: Os dados do DM serao salvos na unified com a request vindo do customer?
• Customer executa processsQuery enviando subscriptionTrue para Unified: Tenant Unificada recebe os dados de subscription?
• processQuery sendo reprocessado na customer, os parametros enviados para unified sao ignorados?
Mensagem editada no Slack - suporte - Douglas Coimbra Lopes
Bom dia pessoal, uma duvida voltado a testes e cenarios esperados voltado ao processQuery na v2 do manifesto . cc
• Customer executa processQuery enviando savetoUnified True: Os dados do DM serao salvos na unified com a request vindo do customer?
• Customer executa processsQuery enviando subscriptionTrue para Unified: Tenant Unificada recebe os dados de subscription?
Mensagem enviada pelo Slack - suporte - Douglas Coimbra Lopes
Novo bug encontrado durante revalidacao do :
• :rotating_light: O mesmo bloqueia qualquer validacao de tasks agendadas de SQL processing com dados
• Tambem bloqueia o reteste do bug de
Mensagem enviada pelo Slack - platform-sre-qa-internal - Douglas Coimbra Lopes
@MARCOS STUMPF ,
@Geny Isam Hamud Herrera , @André Pereira de Oliveira , @Cindy de Araujo Soares Moore , @Douglas Coimbra Lopes , @Lucas Noetzold , @Reinaldo Oliveira Machado Junior
Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/CAPL-6088#icft=CAPL-6088,https://totvsideia.atlassian.net/browse/CAPL-6214#icft=CAPL-6214, conforme menções feitas no comentário anterior.
UPDATE: O card da Cindy https://totvsideia.atlassian.net/browse/CAPL-6088 deve finalizar ainda hoje, porem o card do Renan https://totvsideia.atlassian.net/browse/CAPL-6214 ainda está em analise.
RISCO DE ENTREGA
Boa tarde pessoal. Uma duvida a respeito do
• Bem como para mantermos a compatibilidade de manifestos v1 e v2, os endpoints de processquery V1,V2 e V3 serao depreciados? Ou manteremos eles existentes com os novos parametros do processQuery? Questionamos isso como provocativa de manter a compatibilidade do que ja vem sendo utilizado em production (Tasks de ORCHESTRATOR)
• Atualmente no codigo o endpoint atual vem depreciado. Obter apenas o endpoint processQuery com os novos parametros esta alinhado ou deve coexistir com o processQuery existente? cc
Mensagem editada no Slack - suporte - Douglas Coimbra Lopes
Boa tarde pessoal. Uma duvida a respeito do
• Bem como para mantermos a compatibilidade de manifestos v1 e v2, os endpoints de processquery V1,V2 e V3 serao depreciados? Ou manteremos eles existentes com os novos parametros do processQuery? Questionamos isso como provocativa de manter a compatibilidade do que ja vem sendo utilizado em production (Tasks de ORCHESTRATOR)
• Atualmente no codigo o endpoint atual vem depreciado cc
Mensagem editada no Slack - suporte - Douglas Coimbra Lopes
Boa tarde pessoal. Uma duvida a respeito do
• Bem como para mantermos a compatibilidade de manifestos v1 e v2, os endpoints de processquery V1,V2 e V3 serao depreciados, ou manteremos eles existentes com os novos parametros do processQuery? Questionamos isso como provocativa de manter a compatibilidade do que ja vem sendo utilizado em production (Tasks de ORCHESTRATOR)
• Atualmente no codigo o endpoint atual vem depreciado cc
Mensagem editada no Slack - suporte - Douglas Coimbra Lopes
Boa tarde pessoal. Uma duvida a respeito do
• Bem como para mantermos a compatibilidade de manifestos v1 e v2, os endpoints de processquery V1,V2 e V3 serao depreciados, ou manteremos eles existentes com os novos parametros do processQuery? Questionamos isso como provocativa de manter a compatibilidade do que ja vem sendo utilizado em production (Tasks de ORCHESTRATOR)
• Atualmente no codigo o endpoint atual vem depreciado cc
Mensagem enviada pelo Slack - suporte - Douglas Coimbra Lopes
:rotating_light: Erro encontrado na branch
• *Ao rodar uma SQL Processing task, a task falha por erro de sintax. Evidenciado na aberta que na develop a mesma SQL Task passa sem er*ros)
Mensagem enviada pelo Slack - plataforma-carol-internal - Douglas Coimbra Lopes
Card retestado durante validacoes do . Pendente code review:
Mensagem enviada pelo Slack - plataforma-carol-internal - Douglas Coimbra Lopes
Github Commit:
@MARCOS STUMPF ,
@Renan Fernando Schroeder , @Lucas Noetzold , @Lucas Noetzold
Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/CAPL-4561#icft=CAPL-4561, conforme menções feitas no campo description.
Esta issue foi automaticamente movimentada para IN PROGRESS, pois teve sua branch criada no Github.
CAPL-6069-unified-subscription
@MARCOS STUMPF ,
@Geny Isam Hamud Herrera ,
Esta issue acabou de ser vinculada na(s) issue(s) https://totvsideia.atlassian.net/browse/CAPL-4561#icft=CAPL-4561, conforme menções feitas no campo description.