Analise feita através do chamado: [https://oystr.bitrix24.com.br/workgroups/group/111/tasks/task/view/211559/?any=group%2F111%2Ftasks%2Ftask%2Fview%2F211559%2F](https://oystr.bitrix24.com.br/workgroups/group/111/tasks/task/view/211559/?any=group%2F111%2Ftasks%2Ftask%2Fview%2F211559%2F)
### O que precisa ter no card: - itemID - Processo - Id/Usuário ### Acessos necessários: - Acesso ao banco de dados - Acesso ao google cloud 1\. Com o **ItemID**, acesse o banco de dados **petitionDB** e execute a pesquisa, conforme abaixo [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/tOBimage.png) 2\. Acesse o **JSON** do **ItemID.** 3\. No **JSON**, você deve procurar: - O campo **`request`**. - Dentro de **`request`**, vão estar: - **`archiveID`** → o identificador do arquivo compactado. - **`location`** → a localização do envio. - **`files{}`** e **`arquivos{}`** → essas seções listam os **dados dos arquivos transmitidos** (nomes, tamanhos, etc.) e permitem verificar **quantos arquivos foram enviados**. [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/8o8image.png) [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/dbyimage.png)Nesse exemplo, ambos possuem apenas uma chave de um único e mesmo arquivo, mostrando que não houve duplicidade.
4\. Retorne ao usuário o id do **request,** finalizando a investigação e pedindo para prosseguirem com o time de RPA. ### Validação na nuvem Nesse ponto, ja existe a primeira validação de que não houve falha processual vindo da parte da aplicação, porém, se quiser verificar sua **saida** dentro do **google cloud storage**, siga os passos abaixo: 1\. Acesse o ambiente do **Google Cloud > oystr-archive-sa > petition-files** 2\. Utilize o campo **location** para rastrear as datas através das pastas. 3\. Utilize o campo **archiveID** para localizar a pasta correspondente. 4\. Dentro da pasta, encontrará todos os arquivos referentes a este protocolo. [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/dG0image.png)Como na imagem acima, se o arquivo é pequeno, se não houver nenhuma anomalia no processo, a chance da duplicidade ter ocorrido pelo robô é grande.
5\. Por fim, se não enviou ainda, retorne ao usuário o id do **request** finalizando a investigação e pedindo para prosseguirem com o time de RPA. # Investigação: Divergencia no prazo.O procedimento tem como objetivo descobrir de onde surgiu a falha no controle de cumprimento do prazo.
### O que precisa ter no card: - itemID para identificação. ### Acessos necessários: - Acesso ao banco de dados ### Passo-a-Passo 1. Acesse o banco de dados petitionDB [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/e3bimage.png) 2. Com o itemID, realize uma pesquisa em **executions.** [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/NN8image.png) 3. Será retornado os valores correspondentes a chave itemID. 4. Acesse através do visualizador JSON e busque pelo campo **cumprirPrazo.** Se ele retorna "sim": a razão da falha ocorreu devido ao robô. [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/Gb1image.png) 5. Para finalização, procure o campo **request** e informe ao cliente, solicitando para que compartilhe com o time de RPA para analise. [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/c58image.png) # Investigação em CPJ: Protocolo recusado por erro ### O que precisa ter no card: - ID do documento e ID de erro do objeto. ### Acessos necessários: - Acesso ao servidor Oystr4 ### Exemplo de caso: [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/Cilimage.png) ### Passo-a-Passo 1\. Com o id do documento, Acesse o servidor Oystr4 e acesse o ambiente abaixo:cd /opt/oystr/cpj-connector/shared/repo/(id do documento)
cat request.log
grep (ID de erro do objeto)
2\. Localize o arquivo através do grep e verifique o log de registro. 3\. Confirme o nome do arquivo e se está com formatação correta para ser reconhecido. -Arquivos que possuam mais de um ponto ( . ) podem ocasionar na recusa, pelo sistema não conseguir reconhecer. # Investigação: Erro ou inconsistencia na gestão de protocolos ### O que precisa ter no card: - ID/Usuário - E-mail - Nome da empresa ### Acessos necessários: - Acesso ao banco de dados - Acesso para incorporar perfil ### Passo-a-Passo 1. Acesse e incorpore o perfil do colaborador 2. Acesse a **gestão de protocolos** do usuário [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/1CDimage.png)Na imagem, é perceptivel que existe 54 inconsistencias.
3.Procure um dos protocolos que apresenta a inconsistencia/erro e copie seu **iD.** 4\. Acesse o **banco de** dados **petition**, e procure a execução através do **ID** copiado. [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/ES3image.png) 5\. Acesse o arquivo json, e procure a chave **"error".** Nela, será informado a razão da inconsistencia. [](https://wiki.oystr.com.br/uploads/images/gallery/2025-09/U7Nimage.png) 6. Retorne ao colaborador, a informação do erro/inconsistencia, finalizando o card. # Protocolos: Validar logs ### Acessos necessários: - Acesso ao Oystr-app-4 - Acesso ao Oystr4 ## Passo-a-Passo ### 1. Log de erros gerais. 1. Acesse o ambiente **Oystr-app-4 -> 104.237.134.86** 2. Navegue até o caminho abaixo:/opt/oystr/petition-service/shared/log
3. utilize o comando **ls** para validar as datas e encontrar a que está procurando. [](https://wiki.oystr.com.br/uploads/images/gallery/2025-10/LqIimage.png) 4. Utilize o código abaixo, de forma ajustada, para realizar a pesquisa mediante a sua necessidade.cat ARQUIVO.log | grep "PALAVRA\_CHAVE"
### 2. Validar log de CPJ 1. Acesse o ambiente **Oystr4 -> 23.239.27.38** 2. Navegue até o caminho abaixo:/opt/oystr/cpj-connector/shared/repo/ID\_DE\_CONTRATACAO
3. Utilize o código abaixo, de forma ajustada, para realizar a pesquisa mediante a sua necessidade.cat ARQUIVO.log | grep "PALAVRA\_CHAVE"
[](https://wiki.oystr.com.br/uploads/images/gallery/2025-10/flTimage.png)