Ontem depois de testar toda a DataLibrary e de realizar a Lógica de Pesquisas, começamos então a tratar do problema do envio de Notificações aos interessados. O Kinjas que está encarregue de realizar um serviço teste, disse-nos uma possível mensagem template no formato XML que poderia ser usada, depois de a analisarmos começamos a discutir a forma de a trabalhar. Discutimos a questão, e a melhor forma que arranjámos foi, em primeiro lugar realizar uma validação a essa mensagem, sendo que essa tarefa irá ser realizada posteriormente, para já vamos admitir que a mensagem é bem formada.
Hoje em principio vamos processar a mensagem e enviar aos interessados.

Esta questão da lógica de pesquisas foi ontem discutida e implementada, o que resolvemos fazer foi o seguinte:
Temos uma classe que representa uma expressão, podendo essa expressão ser, ou uma expressão simples, ou uma expressão complexa.
Dessa classe derivámos uma expressão binária e uma expressão constante, uma expressão binária tem um lado esquerdo e um lado direito, cada um desses lados é uma outra expressão, a expressão constante apenas retorna um valor. Da expressão binária derivámos as expressões que vão ser utilizadas na lógica de pesquisas, sendo elas OrExpression, AndExpression, EqualExpression, LessExpression, LessEqualExpression, .....
Assim nos webservices o que tivémos que fazer foi colocar a tag [XMLInclude(....)] com todos os tipos de expressões possíveis, pois quem ia chamar o método apenas conhecia o objecto Expression, com a tag XMLInclude, quem chama o método conhece todos os objectos que derivam de expression, pois foram postos dentro da Tag.
O UML correspondente irá ser colocado aqui no post um dia destes.

Este é outro problema do qual hoje queria discutir com o Kinjas e com o Rui, daí colocar aqui para não me esquecer.

Depois de uma discussão saúdavel, decidiu-se implementar um mecanismo de excepções simples, mas coerente para a plataforma.
As excepções são apanhadas desde a camada DataLibrary, em que são guardadas, não só a informação detalhada da excepção que ocorreu mas também uma "friendly message". A camada acima faz throw dessa excepção e acrescenta informação da sua camada. Por fim na camada dos WebServices é guardado num ficheiro de log todo o encapsulamento das excepções, contudo a informação enviada ao utilizador final é uma "friendly message", ou seja, algo do género, erro ao tentar registar o Serviço XPTO, claro que no log está descrita toda a exepção para o administrador verificar se é uma excepção prevista, ou se é necessário corrigir algum problema.
Hoje vamos actualizar o Serviço de Negócios colocando a classe que dá suporte as subscrições dos utilizadores num dado serviço. De seguida logo se vê....... Em todo o caso NÃO VAMOS DESANIMAR COM O QUE FALTA, MAS SIM DIZER PARA NÓS PRÓPRIOS QUE JÁ FALTOU MAIS.......
Temos de pensar positivamente. :)

É importante que se realize um teste exaustivo a todo o Projecto da DataLibrary, desde a criação de por exemplo um ServiceProvider, até a tentativa de criação de um objecto que não seja válido, por forma a verificar tanto a criação de objectos válidos bem como os inválidos. Pois quanto mais tarde detetarmos os erros pior é.

Por forma a implementar a lógica de pesquisas foi discutida uma possível solução, passando essa pela criação de uma classe que pudesse representar a expressão a avaliar, isto porque podem aparecer pesquisas de qualquer tipo a avaliar, dois exemplos são os seguintes:

1- select * from X where z= 2 and y='provider1' or f!=3
2- select * from X where z= 2 and y='provider1' and f = 3

Ou seja, nada garante que só por exemplo expressões de lógica iguais em toda a expressão sejam válidas, conforme os dois exemplos anteriores, o utilizador tanto pode fazer pesquisas do tipo 1 como do tipo 2.

Durante o ínicio da próxima semana acho que é importante esta classe ficar concluída com sucesso, pois existem muitas funcionalidades que poderão ficar mais facilmente realizadas com sucesso após a realização desta classe.

About Unhandled Exceptions
The great thing about a good global exception handler is that it makes the rest of your code easier to read. Rather than cluttering up your code with Try..Catch blocks for every possible error condition, no matter how rare, you can simply rely on the solid, built-in global handler to deal with those oddball scenarios-- and to notify you when they happen!
So then the natural question that most developers ask is, "When should I catch exceptions"? And it's a very good question. Here are some guidelines that I have found useful.

• Unless you have a very good reason to catch an exception, DON'T. Exceptions are supposed to be exceptional, just like the dictionary meaning: uncommon, unusual. When in doubt, let the calling routine, or the global exception handler, deal with it. This is the golden rule. The hardest kinds of exceptions to troubleshoot are the ones that don't even exist, because a developer upstream of you decided to consume it.
  


• If you can correct the problem implied by the exception. For example, if you try to write to a file and it is read-only, try removing the read-only flag from the file. In this case you handled the exception and fixed the problem, so you should eat the exception. It doesn't exist, because you fixed it.


• If you can provide additional information about the exception. For example, if you fail to connect via HTTP to a remote website, you can provide details about why the connection failed: was the DNS invalid? Did it time out? Was the connection closed? Did the site return 401 unauthorized, which implies that credentials are needed? In this case you want to catch the exception, and re-throw it as an inner exception with more information. This is a very good reason to catch an exception, but note that we are still re-throwing it!


• Always try to catch specific exceptions. Avoid catching System.Exception whenever possible; try to catch just the specific errors that are specific to that block of code. Catch System.IO.FileNotFound instead.

Com esta história das Roles dos utilizadores, foi necessário efectuar umas actualizações ao modelo de dados que tinhamos. Aqui fica a nova versão:

Este é mais um ponto de discussão da nossa plataforma. Existem métodos de determinadas classes que devem ser publicos (WebMethod's) mas só podem ser chamados por utilizadores autorizados. Por exemplo:
o método Notify(Message m), que tal como os outros métodos, tb está disponível para o mundo (WebMethod), não deve poder ser chamado por qq utilizador. Apenas por detentores de serviços de notificação. Caso contrário qq utilizador malicioso criava um proxy para para a plataforma e chamava o método Notify(...) fazendo-se passar, por exemplo, pelo serviço de notificação de incêndios...

Para isso vamos ter que inserir um novo conceito na plataforma, e começa por reflectir-se na BD, que é o conceito de Role

Existem vários tipos de Roles, como por exemplo, Administrator, Manager, Teller, ... , em que cada um terá permissões diferentes para executar determinados métodos.

Pontos a focar na próxima reunião:

• Tratamento de Excepções

• Lógica de pesquisas PISNA

Após algum diálogo optámos por remodelar a lógica de pesquisas na PISNA seguindo o seguinte diagrama de classes
Com esta “funcionalidade” acrescida, implementada na camada de negócios da PISNA pretende-se que as aplicações cliente possam criar expressões de pesquisa a base de dados.

• A lógica de pesquisas a implementar não invalida a necessidade de filtrar as expreções pré-pesquisa, para evitar situações de possivel abuso das funcionalidades disponibilisadas pelo SQL server (como comandos shell...).


• schema para validar o formato das notificações dos SN


• “schema” para actualização do diagrama de classes e script sql
  schema + XML para mostrar info de cliente na altura da subscrição


• Separação entre o que é info. Necessária para os SN e info. Necessário para a PISNA na altura da subcrição.