Short dump no Proxy ECC

[former_member537096]

Ola pessoal

Estou capturando um erro, exporádico, quando o proxy ECC é executado.

Essa é um proxy de entrada com direcionamento para uma fila especifica no ECC.

Erro:

<SAP:Stack>Short dump occurred when executing message in
qRFC queue XBQRTCFL_CREATE: Date/time 27.08.2015 16:37:36, user DDIC, runtime
error: Document 91809579 1001 is locked by another user</SAP:Stack>

O erro quando disparado não é enviado para a ST22

Bloqueando a fila e todos os registros emplilham, impactando e muito.

Estou precisando de ajuda com essa questão. \o/

obrigado

[Former Member]

Olá Grazziani

Você precisa detalhar um pouco melhor o cenário para podermos entender e ajudar.

Que RFC este proxy executa?

Pela descrição, o erro ocorre quando um billing document está em lock e não consegue executar a função. Mas se você der os detalhes do cenário é mais fácil ajudar, para ver que tratamentos de erro é possível implementar.

[former_member537096]

Bom dia Luiz,

Esse é um proxy IN chama um metodo e dentro do metodo temos uma FM Z (comun) que recebe um arquivo para geração de OV / doc. Faturamento e posteriormente altera o campo XBLNR (BKPF-VBRK-BSID), concatenando o CTE + o numero do doc gerado.

Mesmo ocorrendo o short dump todo o processamento é concluido com sucesso, creio que o erro está no retorno para o XI com o status de sucesso.

Tentei tratar o short dump com um try/catch mas sem sucesso.

O nosso problema hoje é que a fila fica travada se houvesse alguma maneira de tratar esse erro.

[former_member182503]

Grazziani,

Você precisa analizar primeiro qual é o motivo do lock no documento de faturamento e na sequência, adequar sua aplicação.

Pelo que você disse, o programa cria uma OV e documento de faturamento. Será que ele não está demorando um pouco para fazer esta criação em momentos de maior carga no sistema(pico) e no momento posterior, quando você tenta efetuar a alteração do mesmo, ele se encontra bloqueado?

Uma tratativa bastante comum neste tipo de cenário é incluir um "WAIT UP TO x SECONDS" após a criação de um documento para aguardar a liberação do lock. Exemplo:

"Cria Ordem de Venda

CALL FUNCTION 'BAPI_SALESORDER_CREATEFROMDAT2'...

...

IF sy-subrc EQ 0 and lv_salesdocument IS NOT INITIAL.

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'...

ENDIF.

WAIT UP TO 5 SECONDS.

"Cria Fatura

CALL FUNCTION 'RV_INVOICE_CREATE'...

Outra técnica é usando um loop do/enddo, especificando um número máximo de tentativas, ex: 5, c/ um tempo de espera entre as tentativas, ex: 5 segundos e se após os 60 segundos você não conseguir criar/alterar o documento por conta do lock, você gera erro.

Exemplo:

DATA: lv_count TYPE i.

WHILE lv_count < 5.

CALL FUNCTION 'RV_INVOICE_DOCUMENT_UPDATE'

...

IF sy-subrc NE 0. "se possível, checando se a mensagem é a mensagem de erro referente ao lock.

ELSE.

EXIT.

ENDIF.

WAIT UP TO 5 SECONDS.

ADD 1 TO lv_count.

ENDWHILE.

São duas técnicas, uma com menos impacto, outra com maior impacto (a segunda deve ser feita com muito cuidado), mas ambas devem resolver o problema.

[]'s

JN

[former_member537096]

Jose,

Obrigado pelas dicas vou buscar implenta-las de forma que o impacto seja o menor possivel na performance.

A BAPI utilizada para a criação do Doc. Fat é

CALL FUNCTION 'BAPI_BILLINGDOC_CREATEMULTIPLE'

Se a tabela de erro não possuir registro type 'E' é chamada a

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'

EXPORT wait = 'X'

Após a criação do doc de fat é utilizado a função CALL FUNCTION 'FI_DOCUMENT_CHANGE' para atualizar o campo XBLNR, mas nos testes que realizei esta somente altera as tabelas BKPF e BSID então foi utilizada outra FM que altera o texto da VBRK CALL FUNCTION 'UPDATE_XBLNR_IN_VBRK'.

Talvez essa sequência que foi utilizada para modificação não tenha sido a adequada.

Outro ponto interessante é que o short dump não é enviado para a ST22, com isso não sei precisar qual é o ponto do erro.

Obrigado..

[former_member182503]

Grazziani,

Você está criando apenas um documento de faturamento por vez, certo?

Pelo fluxo descrito por você, o erro deve ocorrer na chamada da função 'UPDATE_XBLNR_IN_VBRK'.

A primeira coisa que a função tenta fazer é bloquear o documento de faturamento, caso contrário, estoura a exception DOCUMENT_BLOCKED.

Após a chamada do CALL FUNCTION 'BAPI_TRANSACTION_COMMIT', coloque o WAIT UP TO 5 SECONDS. e veja se diminui a ocorrência do erro.

Outra coisa, na chamada da função 'UPDATE_XBLNR_IN_VBRK', as EXCEPTIONS estão declaradas?

Exemplo:

CALL FUNCTION ''UPDATE_XBLNR_IN_VBRK'

EXPORTING

I_VBELN = lv_vbeln

I_XBLNR = lv_xblnr

IMPORTING

E_XBLNR = lv_xblnr_e

EXCEPTIONS

DOCUMENT_BLOCKED = 1

UPDATE_NO_SUCCESS = 2

OTHERS = 3.

IF sy-subrc EQ 0.

...

ELSE.

...

ENDIF.

Se não estiver assim, pode ser o motivo de estar bloqueando sua filas e você não conseguir tratar o erro.

Para tentar ver o problema, na SQ01/SQ02, você consegue selecionar o LUW onde ocorreu o erro e debugar, assim como analisar na SM58/SM14.

Outra dica: utilize o BAL para criar logs:

Application Logging in SAP Using ABAP - Code Gallery - SCN Wiki

[]'s

JN

[former_member537096]

Bom dia JN,

Já implementei o wait após a bapi_commit e inicei a faze de testes com a integração... , cenas para os próximos capitulos.

Na função UPDATE_XBLNR_IN_VBRK já estava declarada com as EXCEPTIONS.

Ontem, creio que encontrei o ponto que dispara a mesma mensagem que o proxy recebe, segue o código que está na FI_CHANGE_DOCUMENT.

Vejo na SE91 qual é a mensagem a ser disparada do tipo 'E'.

Agora é aguardar os testes e torcer..

Obrigado pela ajuda e dicas...!