Sap edocument process manager

Vanessa Santana, sua separação por tipo de erro é o caminho certo. Eu acrescento um ponto: no ambiente de qualidade, ó, a gente sempre roda o cenário antes de tocar na produção, porque o process manager reage diferente quando o parceiro de negócio muda. Dá para copiar o cenário e comparar lado a lado. Sem essa comparação, a correção vira tentativa e erro, e o edocument volta a travar na semana seguinte.

Não tenho tanta certeza disso. Por assim dizer, tá, copiar o cenário ajuda, mas o ambiente de teste quase nunca tem o mesmo volume de dados nem o mesmo parceiro que a produção. Discordo da Juliana nesse ponto, porque a comparação fica incompleta. Na minha equipe, a gente testa com um lote pequeno da produção espelhado e só depois passa a correção. É mais trabalho, mas o process manager responde de outro jeito quando o dado é real.

O risco que eu já vi é o time reprocessar em massa sem entender a causa, e isso ainda duplica o edocument em alguns casos. Olha, no rollout a nossa equipe adotou outro caminho: separa os documentos parados por tipo de erro, corrige a configuração do process manager só para o grupo afetado e só então reprocessa. Vale mais quando a quantidade é alta e o erro se repete. Para caso isolado, o reprocessamento unitário com print do status ainda resolve mais rápido.

Concordo em parte com o Daniel, o histórico de aprovação merece atenção. Mas puxando o fio, ó, no nosso caso o que travou o process manager foi o status do evento de origem, que ficou pendente e nunca virou erro. Isso engana, porque a tela mostra o edocument como em andamento. Eu incluiria uma checagem de evento pendente antes do histórico, porque ela é rápida e tira muita dúvida da frente.

Será que o problema é sempre a condição? Veja, resumindo, eu discordo de um ponto que a Viviane colocou. Ela disse que, em geral, nada chega a nascer. Na minha experiência com o process manager, o edocument existe e fica parado numa etapa de aprovação que ninguém configurou direito. Por isso eu começaria pelo histórico de aprovação e só depois pelo evento de origem. Não é regra, é o que vi num projeto de construção com RISE.

Bem, aqui na empresa, na minha rotina, eu mexo no código de enriquecimento antes do process manager e costumo ver o edocument criado mas sem status de envio. Viviane, você falou do evento de origem. Bem, aqui na companhia o evento chega, mas o status fica em branco. Isso aponta para a condição de disparo ou para o próprio processo? Queria saber onde você olha primeiro nesse caso.

Quando o edocument fica parado no process manager, eu olho primeiro o status do evento de origem e não o da fila de envio. O fato é que, ó, na maioria dos casos o documento nem chegou a ser criado porque a condição de disparo não foi atendida. Depois que confirmo isso, comparo o log da execução com a configuração do processo e só então mexo em alguma coisa. Se você trouxer o print da tela de status e o log do job, dá para ver rápido onde a corrente quebrou.