{"id":1338,"date":"2017-08-08T11:17:11","date_gmt":"2017-08-08T14:17:11","guid":{"rendered":"http:\/\/gianfratti.com\/?p=1338"},"modified":"2017-08-10T15:21:35","modified_gmt":"2017-08-10T18:21:35","slug":"tracing-em-servicos-wcf","status":"publish","type":"post","link":"http:\/\/gianfratti.com\/index.php\/tracing-em-servicos-wcf\/","title":{"rendered":"Tracing em servi\u00e7os WCF"},"content":{"rendered":"

Toda e qualquer tipo de aplica\u00e7\u00e3o sempre exige uma forma de armazenar poss\u00edveis erros que possam acontecer durante a sua execu\u00e7\u00e3o. Isso ir\u00e1 ajudar imensamente para diagnosticarmos problemas que ocorrem e, conseq\u00fcentemente, facilitar na sua solu\u00e7\u00e3o. Isso n\u00e3o \u00e9 diferente em servi\u00e7os WCF. Esse artigo tem a finalidade de demonstrar a integra\u00e7\u00e3o que os servi\u00e7os WCF possibilitam para a captura e persist\u00eancia dos erros para uma posterior an\u00e1lise.
\n<\/span><\/p>\n

Felizmente, o WCF j\u00e1 t\u00eam embutido em sua infraestrutura uma integra\u00e7\u00e3o muito forte com o namespace System.Diagnostics<\/i> que, por sua vez, fornece toda a parte de monitoramento da “sa\u00fade” das aplica\u00e7\u00f5es constru\u00eddas sob a plataforma .NET. O monitoramento n\u00e3o est\u00e1 habilitado por padr\u00e3o e, para isso, basta configurarmos algumas informa\u00e7\u00f5es necess\u00e1rias para o funcionamento do mesmo dentro do arquivo *.config<\/i>.<\/p>\n

\u00c9 bom informar que, como pr\u00e9-requisito para este artigo, voc\u00ea precisa conhecer as principais funcionalidades que s\u00e3o disponibilizadas pelo System.Diagnostics<\/i>. O WCF j\u00e1 define alguns trace sources<\/i> que voc\u00ea pode estar utilizando para efetuar os logs<\/i>. Entre os trace sources<\/i> dispon\u00edveis temos um chamado System.ServiceModel<\/i>. Este trace source<\/i> loga todos os est\u00e1gios de um processamento de um servi\u00e7o WCF, que vai desde a cria\u00e7\u00e3o do mesmo, passando pela autentica\u00e7\u00e3o e transporte da mensagem, at\u00e9 o retorno do m\u00e9todo. O c\u00f3digo abaixo trata-se de um trecho do arquivo App.Config<\/i>, que foi extra\u00eddo de uma aplica\u00e7\u00e3o que consome o servi\u00e7o WCF:<\/p>\n

<\/p>\n\n\n\n\n
\n
<system.diagnostics>\r\n  <sources>\r\n    <source\r\n      name=\"System.ServiceModel\"\r\n      switchValue=\"All\"\r\n      propagateActivity=\"true\">\r\n      <listeners>\r\n        <add\r\n            name=\"TraceInXml\"\r\n            type=\"System.Diagnostics.XmlWriterTraceListener\"\r\n            initializeData=\"C:\\AppLog.svclog\" \/>\r\n      <\/listeners>\r\n    <\/source>\r\n  <\/sources>\r\n  <trace autoflush=\"true\" \/>\r\n<\/system.diagnostics><\/pre>\n<\/td>\n<\/tr>\n
App.Config<\/b><\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\nAnalisando o trecho de c\u00f3digo acima, especificamos o source<\/i> como sendo System.ServiceModel<\/i> para ser capaz de capturar todos os est\u00e1gios do processamento do WCF. O elemento source<\/i> possui dois outros atributos, chamados: switchValue<\/i> e propagateActivity<\/i>. O primeiro deles, switchValue<\/i>, recebe uma combina\u00e7\u00e3o de valores (separados por v\u00edrgula) que especifica quais ser\u00e3o os tipos de informa\u00e7\u00f5es que ser\u00e3o capturadas, ou seja, uma esp\u00e9cie de filtro. Como h\u00e1 v\u00e1rias possibilidades, a tabela abaixo descreve cada uma delas:<\/span><\/p>\n

 <\/p>\n\n\n\n
\n\n\n\n\n\n\n\n\n\n\n\n
N\u00edvel<\/b><\/span><\/td>\nDescri\u00e7\u00e3o<\/b><\/span><\/td>\n<\/tr>\n
Off<\/span><\/td>\n\n

Nenhum tipo de informa\u00e7\u00e3o \u00e9 capturada.<\/span><\/p>\n<\/td>\n<\/tr>\n

Critical<\/span><\/td>\n\n

Somente eventos considerados “negativos” s\u00e3o capturados, ou seja, eventos que indicam um processamento inesperado ou um erro condicional. Neste cen\u00e1rio, algumas exce\u00e7\u00f5es n\u00e3o tratadas s\u00e3o capturadas e devidamente logadas. Entre essas exce\u00e7\u00f5es temos: OutOfMemoryException<\/i>, ThreadAbortException<\/i>, StackOverflowException<\/i>, entre algumas outras.<\/span><\/p>\n<\/td>\n<\/tr>\n

Error<\/span><\/td>\n\n

Somente eventos considerados “negativos” s\u00e3o capturados, ou seja, eventos que indicam um processamento inesperado ou um erro condicional. Neste cen\u00e1rio, todo e qualquer tipo de exce\u00e7\u00e3o n\u00e3o tratada \u00e9 capturada e devidamente logada.<\/span><\/p>\n<\/td>\n<\/tr>\n

Warning<\/span><\/td>\n\n

Somente eventos considerados “negativos” s\u00e3o capturados, ou seja, eventos que indicam um processamento inesperado ou um erro condicional. Refere-se a problemas que acontecem na sua aplica\u00e7\u00e3o, mas ela \u00e9 capaz de continuar trabalhando.<\/span><\/p>\n<\/td>\n<\/tr>\n

Information<\/span><\/td>\n\n

Somente eventos considerados “positivos” s\u00e3o capturados, ou seja, eventos que indicam o sucesso de uma determinada tarefa.<\/span><\/p>\n<\/td>\n<\/tr>\n

Verbose<\/span><\/td>\n\n

Somente eventos considerados “positivos” s\u00e3o capturados, mas com a diferen\u00e7a em rela\u00e7\u00e3o ao Information<\/i>, de que estes eventos s\u00e3o considerados de “baixo n\u00edvel”, \u00fateis em procedimento de debugging<\/i> ou otimiza\u00e7\u00e3o.<\/span><\/p>\n<\/td>\n<\/tr>\n

ActivityTracing<\/span><\/td>\n\n

Permite capturar eventos que est\u00e3o contidos dentro uma determinada atividade. As atividades s\u00e3o abordadas de forma mais detalhada logo abaixo.<\/span><\/p>\n<\/td>\n<\/tr>\n

All<\/span><\/td>\n\n

Todo e qualquer tipo de evento (que vimos acima) s\u00e3o capturados e devidamente logados.<\/span><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Observa\u00e7\u00e3o:<\/b> Atente-se aos tipos de evento (filtro) que se aplica ao tracing<\/i>. Utilize isso com uma restri\u00e7\u00e3o muito grande, definindo somente o que voc\u00ea precisa realmente capturar em sua aplica\u00e7\u00e3o\/servi\u00e7o. Dependendo, voc\u00ea pode estar for\u00e7ando o runtime<\/i> a salvar informa\u00e7\u00f5es desnecess\u00e1rias, comprometendo a performance da aplica\u00e7\u00e3o.<\/p>\n

O segundo atributo \u00e9 o propagateActivity<\/i>. Ele \u00e9 utilizado quando o atributo switchValue<\/i> estiver definido como ActivityTracing<\/i>, e recebe um valor booleano indicando se a atividade deve ou n\u00e3o ser propagada para os endpoints<\/i> que participam do processo. Veremos mais detalhes sobre atividades e propaga\u00e7\u00f5es a seguir. E, finalmente, depois do source<\/i> configurado, devemos definir um listener<\/i> (ou v\u00e1rios) que ser\u00e1 respons\u00e1vel por persistir as informa\u00e7\u00f5es em formato XML (quando utilizar o XmlWriterTraceListener<\/i>) mas, como o WCF se utiliza dos listeners<\/i> contidos dentro do namespace System.Diagnostics<\/i>, nada impede de utilizar o TextWriterTraceListener<\/i> e gerar o output<\/i> em formato texto.<\/p>\n

Atividades<\/b><\/p>\n

As atividades s\u00e3o unidades de processamento que nos ajudam no processo de identifica\u00e7\u00e3o de uma poss\u00edvel falha. Essas atividades agrupam todos os traces<\/i> para cada unidade de processamento, facilitando o rastreamento de poss\u00edveis falhas que possam vir a ocorrer durante a execu\u00e7\u00e3o de um determinado servi\u00e7o WCF. As atividades est\u00e3o sempre relacionadas e com o aux\u00edlio de uma ferramenta chamada Service Trace Viewer<\/i> (mais abaixo falaremos sobre ela) poderemos visualizar o processo de forma gr\u00e1fica.<\/p>\n

Quando falamos de atividades, \u00e9 importante saber que elas podem acontecer tanto no cliente quanto no servidor. Sendo assim, \u00e9 importante que as atividades entre cliente e servidor tamb\u00e9m estejam relacionadas para conseguirmos mescl\u00e1-las e, conseq\u00fcentemente, termos uma visualiza\u00e7\u00e3o completa do processo. Para que isso seja poss\u00edvel, h\u00e1 uma t\u00e9cnica chamada propaga\u00e7\u00e3o de atividade<\/i>. Quando esse recurso \u00e9 habilitado, uma esp\u00e9cie de ID \u00e9 gerado e enviado no header<\/i> da mensagem, justamente para correlacionar as atividades atrav\u00e9s das aplica\u00e7\u00f5es. Como vimos no exemplo acima, para habilitarmos a propaga\u00e7\u00e3o, definimos como True<\/i> o atributo propagateActivity<\/i> do elemento source<\/i>.<\/p>\n

Service Trace Viewer Tool (SvcTraceViewer.exe)<\/b><\/p>\n

Este utilit\u00e1rio nos ajuda a analisar e dignosticar os traces<\/i> que s\u00e3o gerados pelos servi\u00e7os WCF disponibilizando, de uma forma bastante simples e intuitiva, a visualiza\u00e7\u00e3o de todo o processo da requisi\u00e7\u00e3o, dividida em v\u00e1rias atividades. Al\u00e9m disso, ele permite selecionarmos v\u00e1rios arquivos, o que permite escolhermos o trace<\/i> gerado pelo cliente e servidor, e a pr\u00f3pria ferramenta mescla as informa\u00e7\u00f5es dos arquivos, apresentando-os da forma que elas realmente acontecem.<\/p>\n

\u00c9 importante dizer que essa ferramenta n\u00e3o \u00e9 disponibilizada apenas com a instala\u00e7\u00e3o do .NET Framework 3.0. Para poder obt\u00ea-la, \u00e9 necess\u00e1rio que voc\u00ea fa\u00e7a o download e instale o Microsoft SDK for .NET Framework 3.0<\/i>, que pode ser encontrado neste endere\u00e7o<\/a>.<\/p>\n\n\n\n\n
\"\"<\/td>\n<\/tr>\n
Figura 1<\/b> – Utilizando o utilit\u00e1rio SvcTraceViewer.exe<\/i> para analisar um tracing<\/i> gerado pelo cliente e servidor.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n


\nSe analisarmos a figura acima, podemos reparar que eu optei por mostrar de forma gr\u00e1fica todo o processo. Logo na parte superior do gr\u00e1fico \u00e9 poss\u00edvel visualizar os processos (cliente e servidor) que fizeram parte da requisi\u00e7\u00e3o para o servi\u00e7o. Neste mesmo gr\u00e1fico ainda \u00e9 poss\u00edvel analisarmos exatamente o momento da cria\u00e7\u00e3o do proxy<\/i>, do host<\/i> e, o principal, do momento onde a exce\u00e7\u00e3o ocorre, que \u00e9 onde o cursor est\u00e1 posicionado. Ainda a respeito do gr\u00e1fico, cada um dos \u00edcones que ali consta representa uma determinada a\u00e7\u00e3o e, para maiores detalhes sobre cada um deles, consulte este documento<\/a>.<\/span><\/p>\n

Esse utilit\u00e1rio permite a cria\u00e7\u00e3o de projetos (*.stvproj<\/i>) de forma que podemos agrupar todos os traces<\/i> relacionados a alguma aplica\u00e7\u00e3o\/servi\u00e7o. Al\u00e9m das v\u00e1rias funcionalidades fornecidas por este utilit\u00e1rio, h\u00e1 uma outra que merece uma aten\u00e7\u00e3o, que \u00e9 o Step Forward<\/i> (F10) ou Step Backward<\/i> (F9). O primeiro permite voc\u00ea avan\u00e7ar para o pr\u00f3ximo trace<\/i> e o segundo permite voltar para o trace<\/i> anterior. \u00c9 bem semelhante ao Step Into<\/i> e Step Over<\/i> do debugger<\/i> do Visual Studio .NET.<\/p>\n

Conclus\u00e3o: <\/b>Que o trace<\/i> \u00e9 essencial em qualquer tipo de aplica\u00e7\u00e3o, isso j\u00e1 n\u00e3o \u00e9 novidade. Felizmente, como pudemos notar neste artigo, o WCF sabe dessa import\u00e2ncia e j\u00e1 incorporou em sua infraestrutura todo o procedimento necess\u00e1rio para gerar os logs<\/i> e disponibilizar para uma posterior an\u00e1lise. Al\u00e9m disso, a utiliza\u00e7\u00e3o da ferramenta Service Trace Viewer<\/i> torna a compreens\u00e3o do processo como um todo muito mais leg\u00edvel e f\u00e1cil de encontrar uma poss\u00edvel falha.<\/p>\n","protected":false},"excerpt":{"rendered":"

Toda e qualquer tipo de aplica\u00e7\u00e3o sempre exige uma forma de armazenar poss\u00edveis erros que possam acontecer durante a sua execu\u00e7\u00e3o. Isso ir\u00e1 ajudar imensamente para diagnosticarmos problemas que ocorrem e, conseq\u00fcentemente, facilitar na sua solu\u00e7\u00e3o. Isso n\u00e3o \u00e9 diferente em servi\u00e7os WCF. Esse artigo tem a finalidade de demonstrar a integra\u00e7\u00e3o que os servi\u00e7os …<\/span> Read More →<\/span><\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[201,200],"tags":[],"class_list":["post-1338","post","type-post","status-publish","format-standard","hentry","category-net","category-troubleshooting"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1338","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/comments?post=1338"}],"version-history":[{"count":1,"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1338\/revisions"}],"predecessor-version":[{"id":1340,"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/posts\/1338\/revisions\/1340"}],"wp:attachment":[{"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/media?parent=1338"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/categories?post=1338"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/gianfratti.com\/index.php\/wp-json\/wp\/v2\/tags?post=1338"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}