Tag uniPaaS JET

JSON em .NET com o Magic xpa

JSON em .NET com o Magic xpa

O formato JSON de estrutura de dados tem se tornado cada vez mais popular, em virtude do aumento da oferta de webServices REST.

Na biblioteca nativa do Magic xpa (uniPaaS), contudo, não encontramos (ainda) funções/rotinas específicas para criar ou ler conteúdos neste formato.

Apenas rotinas para XML estão disponíveis.

Por isso que para manipular dados recebidos no formato JSON, no Magic xpa, precisamos primeiro convertê-los para XML. E quando precisamos disponibilizar dados em JSON, fazemos a conversão inversa: XML para JSON.

Neste post anterior, mostramos como usar classes Java para fazer esta conversão (tanto no Magic xpa quanto no Magic xpi (iBOLT) ).

Mas é claro que esta não é a única maneira.

A conversão pode também ser feita via .NET. É Inclusive mais prático fazer desta forma com o Magic xpa (2.0 ou RIA).

Neste outro post, citamos um exemplo envolvendo HASH para mostrar que sempre que necessitarmos uma funcionalidade (ou rotina) nova no Magic xpa, podemos facilmente criá-la com o .NET e incorporá-la à nossa solução.

No caso do JSON não seria diferente.

Podemos criar a rotina de conversão, nativamente no Magic xpa:

 

 

Leia mais…

Webinar: Desenvolvendo Apps para BlackBerry com uniPaaS

Como desenvolver uma aplicação para BlackBerry com uniPaaS 

É com muita satisfação que apresentamos a versão em português do webinar “Desenvolvendo Apps para BlackBerry em uniPaaS”, apresentado originalmente em inglês pela Magic Software Enterprises. O objetivo é facilitar a compreensão desta apresentação-tutorial, que pode até ser considerado um treinamento, para mostrar à você como é fácil e natural o desenvolvimento uniPaaS para BlackBerry. Aproveite!

 

 Parte 1:

 

Parte 2:

 

Magic Software Brasil

 

Soluções WEB/Enterprise com o uniPaaS – Parte 02

Manoel Frederico

No post anterior falamos sobre a arquitetura de soluções WEB/Enterprise (corporativas) com o uniPaaS. Vamos agora falar sobre instalação e configuração.

Instalação

O uniPaaS é um produto único. Não existem pacotes diferenciados de instalação para XPress/Open Client e Enterprise Server. Sempre será usado o mesmo instalador:

 

No mesmo ambiente instalado pode-se executar (iniciar) o deployment (runtime) tanto em modo On-Line quanto Enterprise Server (AppServer). A diferença entre estes modos de execução é definida apenas pela licença utilizada e algumas configurações do MAGIC.INI.

Em toda a instalação podemos encontrar os elementos que compõem a arquitetura Enterprise Server:

O “AppServer”

O “Broker”

O “Requester” OS Shell

NOTA: “MGrqcmdl.exe” é o Requester para MS-Windows. Para outros SOs, muda o nome do programa.

 

O “Requester” HTTP ISAPI

NOTA: “MGrqispi.dll” está disponível apenas na plataforma MS-Windows, e existem versões diferenciadas para 32 e 64bits.

 

O “Requester” HTTP CGI

NOTA: “MGrqcgi.exe” é o Requester para MS-Windows. Para outros SOs, muda o nome do programa.

Lembrando que os Requesters EJB e OCX não são distribuídos com a instalação, mas gerados pelo desenvolvedor com base no projeto a ser criado, conforme mencionamos no outro post.

Então, resumindo, todo pacote de instalação uniPaaS está preparado para criar tanto ambientes de soluções (aplicações) On-Line (XPress/Open Client), quanto de Serviços (Enterprise Server).

NOTA: “Serviço” aqui significa ‘serviço de aplicação’, baseado em regras de negócio.

 

Configuração do “AppServer”

Como mencionado acima, a diferença entre estes modos de execução (On-Line e Enterprise Server) é definida apenas pela licença utilizada e algumas configurações do MAGIC.INI.

Para se montar a arquitetura Enterprise Server do uniPaaS, é preciso o seguinte:

1)      O deployment (uniRTE.exe) deve ser executado com uma licença apropriada: MGENT1/MGENT2 ou MGRIA.

MGRIA = Esta licença permite que o AppServer atenda requisições de um client RIA (RichClient). Este tipo de client será abordado com detalhes em próximos posts.

NOTA: Este tipo de licença também é comumente chamado de licença RIA.

MGENT1 = Esta licença permite que o AppServer atenda requisições de qualquer client, exceto RIA (RichClient), desde que o uniPaaS esteja instalado em plataformas Intel.

NOTA: Este tipo de licença também é comumente chamado de licença Server, licença AppServer ou licença Enterprise Server.

MGENT2 = Funcionalmente idêntica a MGENT1, esta feature é destinada a plataformas não Intel (ex: IBM iSeries, SUN Sparc…).

NOTA: É possível combinar as licenças MGENT? E MGRIA no mesmo AppServer, para conceder a ele a capacidade de atender a qualquer tipo de requisição suportada.

2)      No MAGIC.INI, algumas configurações da seção MAGIC_ENV precisam ser definidas:

ActivateRequestsServer = Y

Esta chave instrui o AppServer a se registrar no Broker. Neste registro, o AppServer informa ao Broker qual aplicação (.ecf) ele carregou e está pronto para servir.

MessagingServer = ???

O AppServer procura por um Broker cfe. configurações que também estão no MAGIC.INI. Esta chave diz qual o Broker deve ser utilizado. Com esta informação, o AppServer consulta a lista de servidores na seção [MAGIC_SERVERS]. Neste cadastro, está a localização (endereço) do Broker: maquina/porta tcp.

NOTA: normalmente o endereço do Broker contém apenas o número da porta tcp, significando que ele está na mesma máquina do AppServer. Mas é possível informar-se uma máquina diferente neste endereço e tornar a arquitetura ainda mais distribuída: Client <==>Requester<==>Broker<==>App Server<==>Database Server

DeploymentMode = B

Esta chave instrui o AppServer a executar (ser ativado) em background. Todo o suporte interno a UI é desligado, e nenhuma tela da aplicação (se existir) será aberta. Isto é um detalhe importante da arquitetura, já que o deployment uniPaaS está atuando como um AppServer e toda interatividade com o usuário da solução está delegada a outra ponta, no client.

Todas estas configurações também estão disponíveis através da interface do uniPaaS Studio:

ActivateRequestsServer: Options -> Settings -> Environment -> Server -> #1

MessagingServer: Options -> Settings -> Environment -> Server -> #2

DeploymentMode: Options -> Settings -> Environment -> System -> #8

Lista de Brokers: Options -> Settings -> Servers

Com estes procedimentos, o deployment (uniRTE.exe) está configurado para ser um AppServer. O projeto (.ecf) que este AppServer carregar será a aplicação que ele estará servindo.

Configuração do “Broker”

O Broker é o elemento (componente) da arquitetura que fica entre o AppServer e o Requester. Ele recebe as solicitações do Requester e as distribui entre os AppServers registrados. Na solicitação recebida, entre outras informações, está o nome da aplicação desejada. O Broker pesquisa qual AppServer está servindo aquela aplicação e direciona a requisição para ele. Havendo mais de um AppServer servindo a mesma aplicação, o Broker faz o load balancing: direciona a requisição para o AppServer que está livre ou tem o melhor histórico de desempenho de resposta. Nas solicitações enviadas pelos Requesters pode haver uma configuração de prioridade. O Broker gerencia as prioridades das requisições para definir quais precisam ser distribuídas primeiro. E é neste momento, na distribuição das requisições entre os AppServers, que entra em ação outra característica da arquitetura: as filas da licença ou nro. de usuários da licença.

Gerenciamento de Filas da Licença

As licenças AppServers (MGENT1 ou MGENT2) possuem um número de total de filas de processamento em sua feature. Quando uma requisição chega até o AppServer, um novo contexto (thread) é aberto por ele para processar o que foi pedido. E enquanto este processamento durar (milissegundos, segundos, minutos ou horas), uma fila da licença estará ocupada. Quando o processamento termina e a resposta está pronta para ser enviada ao solicitante (o client), esta fila é liberada. O Broker sabe quando o AppServer está ocupado (em processamento) e alocando uma fila da licença. Por isso, quando uma requisição chega do Requester para ser distribuída, o Broker verifica os total de filas que existem nas licenças usadas pelos AppServers e total que estão sendo ocupadas naquele momento. Havendo fila disponível nos AppServers que estão servindo a aplicação especificada na requisição, a solicitação é distribuída de imediato. Senão, ela fica “enfileirada” até haver uma liberação, ou até estourar o timeout configurado no BrokerEste outro post comenta também a respeito deste sistema de filas. Quando mais de um AppServer vão usar a mesma licença, o total de filas da feature precisa ser dividido entre eles. Isto é feito pela chave MaxConcurrentRequests na seção [MAGIC_ENV] do MAGIC.INI do AppServer. Então, dois AppServers (A e B) usando a mesma licença que possui um total de 9 filas, poderiam estar divididos com 5 para (A), e 4 para (B). Para que não haja desperdício de filas (quando (B) não possui mais filas disponíveis para as novas requisições, mas (A) está com filas livres), o Broker possui um mecanismo chamado Float License. Isso permitiria o AppServer (B) usar uma fila “emprestada” do AppServer (A). Mais detalhes deste mecanismo estão disponíveis neste link do DevNet.

Gerenciamento de Usuários Simultâneos

As licenças RIA (MGRIA) usam um mecanismo muito similar ao das aplicações/soluções On-Line (XPress/Open Client) que não está relacionado a filas de processamento, mas ao total de usuários conectados simultaneamente no AppServer. A feature MGRIA possui um número total de usuários permitidos, e quando um novo usuário entra no client RIA e estabelece conexão com o AppServer, o número de novas conexões possíveis é diminuído em um. Um usuário só pode se conectar através do client RIA quando o número de usuários já conectados ainda não atingiu o limite da licença. Assim que um usuário desconecta (fecha) a sua sessão RIA com o AppServer, o número de novas conexões possíveis é aumentado em um. Mais detalhes sobre a licença MGRIA estão disponíveis neste link do DevNet.

Voltando ao Broker: o programa do Broker é o uniRQBroker.exe. Quando iniciado (executado), ele procura por um arquivo chamado MGRB.INI, para ler algumas diretrizes sobre o seu funcionamento. Também é possível informar um .INI diferenciado através da linha de comando do uniRQBroker.exe, no formato: -ini=<nome do INI>. Neste arquivo .INI, na seção [MRB_ENV], existem algumas chaves importantes:

BrokerPort = É o número da porta tcp que será usada para escutar (listen) requisições vindas dos Requesters, e também solicitações de registro de AppServers.

PasswordSupervisor = É uma senha que o AppServer precisa usar para que seu registro seja permitido. O Requester também precisa informá-la em suas requisições enviadas.

A seção [APPLICATIONS_LIST] também é importante, mas será discutida mais adiante. Mais detalhes sobre este arquivo .INI do Broker estão disponíveis neste link do DevNet.

O Broker é o componente da arquitetura que pode ser registrado como serviço do sistema operacional (e não o AppServer). O AppServer estará debaixo das credencias do usuário que iniciou o serviço do Broker, e de suas diretivas e políticas de acesso, mas continuará sendo um processo separado no sistema operacional (MS-Windows por exemplo). Estes dois processos (Broker e AppServer) ficam conversando entre si via comunicação tcp, mesmo quando estão na mesma máquina. Neste outro post há mais informações a respeito de como instalar o Broker como serviço.

Existem duas maneiras de se colocar o Broker (uniRQBroker.exe) e os AppServers (uniRTE.exe) “no ar”:

  • Indireta = Inicia-se o AppServer (uniRTE.exe) e por ele estar com a chave [MAGIC_ENV]ActivateRequestsServer=Y, ele sabe que precisa se registrar em um Broker. Se não encontrar nenhum na porta tcp que está pesquisando, inicia automaticamente o programa uniRQBroker.exe e aguarda até ele ficar disponível para completar o seu registro.

NOTA: esta é a forma mais comum nos ambientes de “desenvolvimento” das soluções web/enterprise com uniPaaS.

  • Direta = Inicia-se o Broker (uniRQBroker.exe), como um processo standalone ou como um serviço do sistema operacional, e ele vasculha a lista [APPLICATIONS_LIST] em seu arquivo .INI (ex: MGRB.INI). Cada AppServer que estiver listado lá, com um número de instâncias maior que 0, é iniciado em um processo separado do sistema operacional. Quando completa a sua carga, o AppServer se registra no Broker.

NOTA: esta é a forma mais comum nos ambientes de “produção” das soluções web/enterprise com uniPaaS: Broker como serviço, e AppServers na [APPLICATIONS_LIST] do Broker.

Desta maneira, com o Broker e os AppServers ativos e cada AppServer com um projeto (.ecf) aberto, nós já estamos com o ambiente web/enterprise do uniPaaS no ar e pronto para atender as requisições vindas dos Requesters.

Com o Broker devidamente “no ar”:

NOTA: Esta tela (acima) não estará disponível quando o Broker estiver rodando com serviço.

Podemos utilizar o Broker Monitor (uniRQMonitor.exe) para acompanhar as atividades das requisições que estão chegando:

 

Configuração dos “Requesters”

O uniPaaS disponibiliza vários Requesters, em diferentes tecnologias, e este é um dos segredos da ampla conectividade que as suas soluções web/enterprise oferecem.

O Requester é a linha de frente da arquitetura. É nele que os diversos clients se conectam para chegarem ao seu objetivo: acessar serviços da aplicação provida pelo AppServer.

Os Requesters usam um arquivo de configurações, o MGREQ.INI, para ler algumas diretrizes sobre o seu funcionamento. É o caso dos Requesters OS Shell e HTTP (ISAPI e CGI).

Neste arquivo.INI, na seção [REQUESTER_ENV], existem algumas informações importantes:

MessagingServer = É a localização do Broker, ao qual a requisição deve ser transmitida. O endereço é no formato maquina/porta tcp.       Se só houver a porta, significa que o Broker está na mesma máquina do Requester.

BrokerTimeout = É o tempo máximo (em segundos) que o Requester irá esperar pela confirmação do Broker à sua solicitação. Se este tempo estourar, pode significar que:

1. Não há Broker neste endereço (erro -102)

2. O Broker não possui a aplicação solicitada, em sua lista de AppServers registrados (erro -103)

3. Os AppServers estão todos ocupados e não há mais filas disponíveis para a esta requisição (erro -104)

Password = Precisa combinar com a “PasswordSupervisor” do Broker, para que ele (Broker) aceite a requisição enviada. Do contrário, ocorrerá um erro de acesso negado (erro -131)

Mais detalhes sobre as configurações do arquivo MGREQ.INI estão disponíveis neste link do DevNet.

A lista de códigos que o Requester pode retornar para o client está disponível neste link do DevNet.

O Requester OS Shell (MGRqcmdl.exe) possui argumentos de linha de comando (ex: -HOST=, -PORT=, -PASSWORD=) para substituição de algumas das chaves de configuração do arquivo MGREQ.INI.

Já os Requesters EJB e OCX funcionam de uma forma diferente. Eles não utilizam configurações do MGREQ.INI. Estes Requesters ficam codificados dentro das classes proxy que o desenvolvedor estiver gerando, e os detalhes da requisição (ex: localização do Broker) são argumentos dos métodos destas classes.

Os Requesters HTTP (ISAPI e CGI) podem ter algumas informações substituídas diretamente na query string (ex: &PASSWORD=???) ou nos campos submetidos via post method. Mas especificamente sobre estes Requesters, algumas configurações adicionais são necessárias.

Por serem módulos ISAPI e CGI eles possuem um pré-requisito: um webServer. Na instalação do uniPaaS é disponibilizada uma pasta chamada Scripts. Nela ficam estes Requesters (ISAPI=MGrqispi.dll e CGI=MGrqcgi.exe) e mais todos os outros arquivos que eles necessitam:

 

Esta pasta precisa ser tornada pública através de um alias no webServer:

 

Isso porque estes Requesters serão acessados na forma de uma URL:

http://<webServer>/<alias>/<requester>[?<argumentos>]. Ex:

http://www.dummycorp.com.br/CorpServices/mgrqispi.dll[&<…>].

Além das pasta Scripts, outras pastas do uniPaaS também precisarão estar publicadas no webServer em função do tipo de aplicação que estará sendo disponibilizada:

  • RIA = precisa-se publicar também a pasta PublishedApplications
  • BrowserClient = precisa-se publicar também a pasta Browser_Client_Cache.

NOTA: Aplicações RIA e BrowserClient dependem dos requesters HTTP (ISAPI ou CGI).

Quando o instalador do uniPaaS está sendo executado (vide primeira imagem) e ele detecta que o MS-IIS está on-line, ele faz esta publicação automaticamente.

Apesar de todas estas pastas estarem instaladas dentro da pasta home do uniPaaS, não é obrigatório que elas sejam compartilhadas (tornadas públicas) dali. Elas podem ser copiadas para outra máquina, onde reside o webServer, e então serem compartilhadas. Isso porque estes Requesters usam o MGREQ.INI para saber onde localizar o Broker e ele pode tranquilamente estar remoto.

Para finalizar em relação aos Requesters HTTP (ISAPI e CGI): após as devidas pastas estarem publicadas no webServer, é preciso informar estes dados no MAGIC.INI do AppServer. Pelo  uniPaaS Studio isso feito através do menu: Options -> Settings -> Environment -> Server. Mas pode também ser editadas diretamente na seção [MAGIC_ENV] do MAGIC.INI:

WebDocumentPath = localização física da pasta “Scripts”

WebDocumentAlias = alias que a pasta “Scripts” ganhou no webServer

InternetDispatcherPath = URL do Requester HTTP padrão

CTLCacheFilesPath = localização física da pasta “Browser_Client_Cache”

CTLCacheFilesAlias = alias que a pasta “Browser_Client_Cache” ganhou no webServer

Desta maneira, concluímos a configuração de toda arquitetura Web e Enterprise  Server do  uniPaaS e estamos prontos para começar a atender as requisições que estarão chegando dos clients.

Lembrando que nesta topologia:

Client<==>WebServer<==>Requester <==>Broker<==>App Server<==>Database Server

Cada nó (sublinhado) pode representar ‘n’ servidores distintos, formando assim uma extensa rede provendo serviços e aplicações.

Sobre os tipos de aplicações que podem ser disponibilizadas, elas se dividem em Request/Response, BrowserClient e RIA.

Mas isto é tema para os próximos posts.

 

Manoel Frederico Silva
Product Manager & MAGIC Evangelist / Magic Software Brasil