Ir para o conteúdo

Configurar alertas, registros e tratamento de erros no Jitterbit Design Studio

Introdução

Um problema comum a ser resolvido é como alertar os usuários sobre problemas de integração, bem como lidar com erros e registrar dados para auxiliar na solução de problemas. Como esses tópicos estão intimamente ligados, nós os abordaremos juntos.

Alerta

O problema é que o middleware é tipicamente um processo de bastidores e precisa ser instrumentado de forma que ele mesmo relate erros ou dados críticos. Caso contrário, um usuário está em um modo reativo, geralmente após a ocorrência de um problema, e é pego de surpresa que há um problema. É muito preferível que o middleware seja configurado para alertar um usuário ou outro sistema com base em regras. A regra mais comum é alertar sobre um erro, mas esse não é o único cenário. Os alertas podem ser para limites atingidos, verificações de integridade ou informações críticas para os negócios.

O Jitterbit tem funções de registro e erro bem como Variáveis do sistema que dão suporte à construção de alertas, registros e tratamento de erros personalizados.

Um padrão comum é identificar cenários de erro esperados, enviar um alerta curto (geralmente email) e registrar informações com mais detalhes.

O principal método de alerta do Jitterbit é via email, e é configurado usando as Mensagens de Email, similar a um Endpoint. Basicamente, o Jitterbit está agindo como um cliente SMTP e, portanto, deve ser conectado a um hospedar.

anexo

Com uma mensagem de e-Email configurada, há várias funções de script que podem ser usadas para instrumentar alertas. Aqui, usamos SendEmailMessage se o NetSuite não puder inserir o registro. Veja Funções de e-Email para mais detalhes.

If(jbroot$jbresponse$addListResponse$writeResponseList$writeResponse.status$isSuccess== true,
WriteToOperationLog("Success Id: "+FindByPos(SourceInstanceCount(),
jbroot$jbresponse$addListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId
)));
If(jbroot$jbresponse$addListResponse$writeResponseList$writeResponse.status$isSuccess== false,
$errormessage="Time Card Entry Error: "+GetEnvironmentName()+" "+
FindByPos(SourceInstanceCount(),
jbroot$jbresponse$addListResponse$writeResponseList$writeResponse#.baseRef$1$RecordRef$internalId)+ " Message: "+
SumString(jbroot$jbresponse$addListResponse$writeResponseList$writeResponse.status$statusDetail#.message$,".",false);
WriteToOperationLog($errormessage);
SendEmailMessage("<TAG>Email Messages/Jitterbit NS Data Error Message</TAG>")
);

Se você quiser enviar um anexo, clique em Enviar email com anexo está disponível.

Tratamento de erros

Há cenários de integração em que o número de casos de erro excede os casos de sucesso, mas é razoável focar nos cenários de erro esperados durante o desenvolvimento e adicionar mais funcionalidades de tratamento de erros como modificações após a entrada em operação.

Nem todos os casos de erro exigem alertas, mas geralmente exigem que o erro seja capturado e registrado para auxiliar na solução de problemas. Em geral, os erros vêm em duas variedades: falhas de operação e erros orientados por dados. A principal distinção é baseada na fonte: falhas de operação são do próprio Jitterbit, enquanto erros orientados por dados são originados do endpoint e o Jitterbit está simplesmente passando adiante.

Falha de operação

A falha de operação é direta e fácil de implementar, onde uma mensagem de email é anexada a uma operação e é enviada se houver uma falha de nível de operação do agente Jitterbit. Um exemplo é se um endpoint, como um banco de dados, for inacessível pelo agente, e uma falha for retornada.anexo

Erros baseados em dados

Cenários típicos baseados em dados incluem:

  • Mensagens ou indicações de status do endpoint.

  • Validação de dados personalizada

  • Dados ausentes ou incompatibilidade de esquema

Registro

Intimamente relacionado ao Alerting está o Logging. O Jitterbit registra informações de nível de operação automaticamente. Em alguns casos, como operações criadas pelo assistente do SFDC, o Jitterbit grava mensagens de falha no log.

Um ponto comum de confusão é como identificar a origem da mensagem de erro, bem como a mensagem em si.

Por exemplo, este erro é de um banco de dados:

ODBC Error : (Insert/Update mode) : SQL = INSERT INTO`[ORDENS_MD] `([SF_ID]) VALUES ('00617000008N2QHAA0')
SqlState = 23000 NativeError = 515
[Microsoft][Driver ODBC do SQL Server][SQL Server]Cannot insert the value NULL into column 'src_Order_ID', table 'MDM_HUB.dbo.MD_ORDERS'; column does not allow nulls. INSERT fails.
SQL Exec Direct = INSERT INTO`[ORDENS_MD] `([SF_ID]) VALUES ('00617000008N2QHAA0')`[CÓDIGO:10618] `file: DbWriter.cpp, line 339
Failed to perform transformation using local source file:
C:/Windows/Temp/jitterbit/OpId_1130166_5e66d5c7-4005-4dd5-9b5e-1c0d593a11cb/1_MDMOpportunitiesSuccess

Um exemplo do NetSuite:

Connector Error: org.jitterbit.integration.server.engine.connector.exception.NetSuiteWebServiceRuntimeException: FaultString: The account you are trying to access is currently unavailable while we undergo our regularly scheduled maintenance.
FaultCode: soapenv:Server.userException
detail.code: ACCT_TEMP_UNAVAILABLE

Um exemplo do Salesforce:

Call to webservice at   https://cs41.salesforce.com/services/Soap/u/33.0/00D5500000065l9   failed. Reported error:
The webservice call failed. The web service returned a SOAP Fault:
Code: sf:INVALID_FIELD
Message: INVALID_FIELD:
Name, SBQQ__Opportunity2__r.Name, SAP_Quote_Number__c, SBQQ__Account__c
^
ERROR at Row:1:Column:42
No such column 'SAP_Quote_Number__c' on entity 'SBQQ__Quote__c'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.

Um exemplo do próprio Jitterbit:

The operation failed unexpectedly. If this issue persists, contact Jitterbit support.
Include as much information as you can with your bug report, such as 'JITTERBIT_HOME/log/OperationEngine.log' and files in 'JITTERBIT_HOME/DataInterchange/Temp/LOG/' so that the problem can be diagnosed.
Also try running the operation with debugging turned on and collect the files generated in DataInterchange/Temp/Debug/

Registro personalizado

É possível adicionar um registro adicional para registrar dados importantes como um auxílio para solução de problemas. Os dados importantes podem ser:

  • Os resultados de uma pesquisa em outro sistema
  • Novos IDs de registro
  • Se estiver usando uma condição para filtrar determinados registros, você pode escrever os cálculos de entrada e saída

A principal função a ser usada é Writetooperationlog() função, como em WriteToOperationLog("Error returned is: " + ...);.

Exemplo

WriteToOperationLog("----------" + "\r\n"
  + "Int id: " + searchResponse$searchResult$recordList$record.SalesOrder$internalId + "\r\n"
  + "Ord id: "+ searchResponse$searchResult$recordList$record.SalesOrder$tranId$ + "\r\n"
  + "LMD: " + searchResponse$searchResult$recordList$record.SalesOrder$lastModifiedDate$ + "\r\n"
  + "Loc: " + searchResponse$searchResult$recordList$record.SalesOrder$location$internalId + "\r\n"
  + "LMB: " + searchResponse$searchResult$recordList$record.SalesOrder$customFieldList$Last_Modified_By$value$internalId + "\r\n"
  + "Cust:" +searchResponse$searchResult$recordList$record.SalesOrder$entity$internalId
);

Log de operação de saída

----------
Int id: 292774
Ord id: OD003374
LMD: 2016-01-29T07:07:41-08:00
Loc: 10
LMB: 10780
Cust:2857
Skip id
----------
Int id: 297849
Ord id: EU000361
LMD: 2016-01-29T07:04:48-08:00
Loc: 17
LMB: 10780
Cust:2048
Skip id
----------
Int id: 299513
Ord id: DFW001852
LMD: 2016-01-29T07:05:15-08:00
Loc: 35
LMB: 108
Cust:12028
Pass
Customer Id: 12028-16067
--Manager: 773