No exemplo da seção Importação baseada nos procedimentos armazenados (exemplo), um procedimento armazenado se inicia e termina cada vez que se solicita uma operação de importação de dados. Neste exemplo, um procedimento armazenado é iniciado automaticamente quando inicia a base do servidor e pode ser iniciado e parado a vontade por qualquer 4D conectado a base. Logo como se executa, o procedimento armazenado pode responder de maneira assíncrona a múltiplos pedidos enviados pelos clientes conectados a base.

Enquanto a seção Importação baseada nos procedimentos armazenados (exemplo), mostra como otimizar um serviço 4D Server existente, este exemplo mostra como implementar serviços novos e personalizados disponíveis para todos as máquinas 4D client conectados. Além disso, este exemplo pode ser utilizado como modelo para a criação de seus próprios serviços.

O procedimento armazenado é lançado automaticamente pelo Método banco de dados On Server Startup:

Como o Método banco de dados On Server Startup lança ao método de projeto SP SERVICES como um procedimento armazenado, SP SERVICES começa a correr logo como a base se abre com 4D Server, tendo ou não clientes conectados à base. Na seguinte imagem, a janela de administração de 4D Server mostra o procedimento armazenado em execução quando nenhum cliente está conectado.

Este é o método de projeto START SP SERVICES:

Como o comando Execute on server atua como New process ao ser chamado na máquina servidor, o mesmo método (START SP SERVICES) pode ser utilizado na máquina servidor ou em uma máquina cliente para iniciar a vontade o método SP SERVICES como um procedimento armazenado na máquina servidor.

O método de projeto STOP SP SERVICES “ordena” parar ao método de projeto SP SERVICES.

Quando é iniciado o método de projeto SP SERVICES, da a variável processo vbStopSPServices o valor False e depois executa um laço até que esta variável Booleana se transforme em True. O comando , permite a todo processo usuário executado no servidor ou em uma máquina cliente modificar o valor da variável vbStopSPServices, e portanto parar o procedimento armazenado a vontade.

O procedimento armazenado deve poder receber pedidos de clientes e responder de maneira assíncrona em qualquer momento e sem importar a ordem. Uma maneira direta de assegurar esta comunicação é utilizar uma tabela.

A tabela [SP Requests] contém os seguintes campos:

• [SP Requests]reqID é assinalado utilizando o comando Sequence number. Este campo identifica cada pedido de maneira única.
• [SP Requests]reqType descreve o tipo do pedido.
• [SP Requests]reqStatus pode tomar um dos seguintes valores:

Nota: Estes valores são escolhidos arbitrariamente para este exemplo, não são impostos por 4D.

• [SP Requests]reqData é um BLOB que contém os dados da petição. Pode conter os dados enviados pela pessoa que solicita os dados devolvidos pelo procedimento armazenado ao requerente.
• [SP Requests]reqParams contém eventualmente os valores dos parâmetros enviados pelo requerente ao procedimento armazenado.

A comunicação entre um processo cliente e um procedimento armazenado pode ser implantado utilizando os comandos GET PROCESS VARIABLE, SET PROCESS VARIABLE e VARIABLE TO VARIABLE. Por exemplo, esta solução utilizada na seção Importação baseada nos procedimentos armazenados (exemplo), como também no método de projeto STOP SP SERVICES listado anteriormente.

Aqui, o sistema deve permitir ao procedimento armazenado receber e reenviar as quantidades das variáveis de dados. Pode utilizar arrays, incluindo arrays de texto e imagem), mas há duas razões principais para preferir o emprego de uma tabela:

• O algoritmo de gestão de petições sob os registros é mais fácil de implementar. Enviar uma petição desde uma máquina cliente consiste simplesmente em adicionar uma petição na tabela. Responder a petição desde o procedimento armazenado consiste simplesmente em modificar esta petição.
• Como as petições se armazenam em uma tabela, são guardadas no disco. Portanto, se o tamanho de uma petição é importante, não será um problema na medida em que possa ser suprimido da memória (a diferença dos dados armazenados nos arrays).

O método de projeto Client post request é um método genérico para enviar uma petição:

O método devolve o número da petição, cuja unicidade está garantida pelo uso do comando Sequence number. Uma vez adicionado o registro a tabela [SP Requests], o cliente não têm que interrogar regularmente o campo [SP Requets]redStatus até que o procedimento armazenado termine de processar a petição.

O método de projeto Client get result é um método genérico para provar o estado da petição. Como foi explicado anteriormente, logo como o campo [SP Requets]redStatus se torna diferente de 1, o cliente sabe que o procedimento armazenado foi tratado (com êxito ou não) a petição.

Se a petição foi administrada com êxito pelo procedimento armazenado, o método copia o resultado (se existe) do registro ao BLOB cujo ponteiro foi passado como parâmetro. O método chamado depois analisa e utiliza os dados do BLOB em função do tipo de pedido. Note que o cliente está encarregado de apagar o registro [SP Requests] uma vez termina o pedido.

O pequeno método de projeto WAITING LOOP faz um laço até um certo número de tics:

Lembrança: DELAY PROCESS não tem efeito no processo principal. Se utiliza o método de projeto WAITING LOOP, o processo esperará a quantidade de tempo necessário, ainda que o pedido tenha origem desde o processo do ambiente usuário de uma máquina cliente.

O método de projeto SP SERVICES é o método executado como procedimento armazenado na máquina servidor. A estrutura geral deste método, a continuação,  muito simples:

Este é o código fonte real:

O método de projeto SP SERVICES pode ser utilizado como modelo para implementar serviços inovadores em uma base. Nesta seção, detalhamos as subrotinas SP DO SERVER INFORMATION e SP DO VOLUME LIST. A subrotina SP DO BROWSE DIRECTORY (que toma como parâmetro um parâmetro enviado pelo cliente no campo [SP Requests]reqParams) não se trata neste documento.

Dependendo do tipo da petição, o método de projeto SP SERVICES chama a uma subrotina cuja tarefa é guardar os dados resultantes no campo [SP Requests]reqData. O armazenamento do registro e a mudança do estado a realizar o método de projeto SP SERVICES.

Esta é a subrotina SP DO SERVER INFORMATION que guarda a informação relativa ao servidor no BLOB. Outro método de projeto extrairá os dados do BLOB em função da máquina cliente.

Esta é a subrotina SP DO VOLUME LIST, que guarda a informação relativa aos volumes no BLOB. Outro método de projeto extrairá os dados do BLOB em função da máquina cliente.

Com os métodos de projeto genéricos Client post request e Client get result, o método de projeto M_SERVER_INFORMATION mostra, na máquina cliente, a informação devolvida pelo procedimento armazenado. Este método pode estar associado a um comando de menu ou ser chamado, por exemplo, desde o método de objeto de um botão:

Este é o formulário [SP Requests];"SERVER INFORMATION" em execução:

Com os métodos de projeto genéricos Client post request e Client get result, o método de projeto M_SERVER_VOLUMES mostra, na máquina cliente, a informação na lista dos volumes do servidor devolvidos pelo procedimento armazenado. Este método pode estar associado a um comando de menu ou chamado, por exemplo, desde o método de objeto de um botão:

Este é o formulário [SP Requests];"VOLUME LIST" em execução: