Disponibiliza padrões para a confecção de plugins, e as APIs que são implementadas por cada plugin que pode ser usado pelo Systêxtil.

Referência adicional: Especificação na página Wiki

Como criar um plugin para o Systêxtil

1. Definir o projeto

Tipo de plugin

É plugin com personalizações para um cliente?

O desenvolvimento do plugin (alocação, construção, distribuição) deve seguir a versão que o cliente está usando.

O nome do plugin e do artefato deve seguir o padrão systextil-plugin-cliente (ou systextil-nome-do-cliente para evitar de ficar muito extenso).

É plugin com lógicas de terceiros?

Se houver interesse em manter o plugin compatível com todas as versões do Systêxtil, é importante que todo o desenvolvimento (alocação, construção, distribuição) não dependa de componentes de negócio do Systêxtil - isto é, de componentes que possuem desenvolvimento controlado em versões. Procurar manter dependência somente de componentes do framework.

Se não houver esse requisito, então o fluxo de desenvolvimento deve seguir, tanto quanto possível, as versões dos clientes que o usam. Por exemplo: se o plugin é somente para clientes Web, então deve seguir as versões de releases para WEB. Se for para todas as versões do Systêxtil, e depender de regras de negócio, então terá que seguir o fluxo completo de controle por versões do Systêxtil.

O nome do plugin e do artefato pode seguir o padrão systextil-nome.

É plugin de módulo opcional do Systêxtil?

Assim como para os plugins de terceiros, se for possível manter uma versão única independente de versões, então é preciso evitar dependências de componentes de negócio. No entanto, normalmente o que se espera é que vá depender desses componentes; sendo assim, terá que seguir o fluxo completo de controle por versões do Systêxtil.

O nome do plugin e do artefato pode seguir o padrão systextil-nome.

Componentes do plugin

Qualquer plugin pode conter todos os tipos de componentes que o Systêxtil usa, como: classes Java, formulários em NXJ, arquivos de ajuda, leiautes de relatórios, scripts SQL e outros. Pode conter todos os tipos, ou somente alguns, ou somente um.

Se o plugin contiver rotinas que modificam ou se adicionam a processos existentes, sendo chamadas por esses processos, então será preciso incluir alterações na API de plugins para poder implementar essas chamadas. Serão chamadas parecidas com:

    Provedor provedor = new PluginClassLoader().getProvider(Provedor.class);
    if(provedor != null) {
        // Executar a lógica que é dependente do provedor do plugin
    } else {
        // Executar a lógica que é usada na ausência de plugin
    }

Se, no entanto, o plugin contiver processos inteiros, então pode não ser necessário alterar as classes da API, pois os formulários do plugin serão chamados diretamente. Mas será preciso incluir os artefatos no classloader conveniente da API (para classes Java e/ou para formulários em NXJ), conforme explicado abaixo.

2. Criar o projeto

Crie a pasta onde estará o projeto no seu workspace, com o nome conforme foi definido acima.
Descompacte ali o conteúdo do arquivo systextil-plugin-template.zip que está disponível na pasta padrão de bibliotecas (que é \\desenv01\lib.
Convém substituir o nome genérico do projeto (que é "systextil-plugin") pelo nome do plugin nos arquivos de configuração, que são .project para o Eclipse e build.xml para o NetBeans.
Importe o projeto para o repositório de códigos-fonte de sua preferência.

A partir daí o projeto pode ser editado usando a IDE de sua preferência (já configurado para Eclipse e NetBeans) e integrado ao controle de versões.

Pode acontecer da IDE remover pastas que não contêm arquivos, depois de integrar o projeto ao CVS (que é o "prune directories"). Se você não quiser que pastas desapareçam antes que você comece a usá-las, é conveniente incluir algum arquivo nelas antes de importar o projeto no CVS.

3. Editar o projeto

O projeto já vem configurado em pastas conforme a finalidade: pastas para códigos-fonte Java, para arquivos de recursos, para testes, para formulários do NXJ, para scripts SQL e para arquivos de texto. Basta editar o projeto como qualquer outro projeto Java do Systêxtil, usando o arquivo build.xml para fazer as construções.

Se o projeto contiver formulários do NXJ, naturalmente será preciso usar o NXJ Developer. O arquivo build.xml tem o alvo make-all que pode ser usado para compilar e gerar os artefatos dos formulários.

O arquivo build.xml ainda não tem alvos para construir ou implantar todos os tipos de artefatos. Isso pode ser solicitado à área de tecnologia quando for necessário.

4. Integrar o projeto

O plugin não servirá para nada se não estiver integrado ao Systêxtil. Para isso, pode ser necessário alterar o projeto systextil-plugins-api para ali definir as classes da API que o plugin vai implementar, se ele vai usar isso. Fazer assim:

Criar a package do plugin (p. ex. systextil.plugin.meuplugin).
Definir a interface do provedor (o nome pode ser Provedor mesmo).
Definir uma ou mais interfaces ou classes abstratas que o provedor vai fornecer.
Se for conveniente, definir um ou mais DTOs para transporte de dados (obviamente).
Se o arquivo do plugin for carregado estaticamente (isto é, no mesmo classloader da aplicação), é preciso incluir o caminho para o artefato na sessão Class-Path dos arquivos manifest.mf e manifest-nxj.mf, conforme o caso.

(Ali já estão presentes alguns plugins que podem servir de exemplo.)

Feito isto, é preciso atualizar o arquivo systextil-plugins-api.jar na pasta de bibliotecas do seu workspace, para que seja implementado pelo projeto do plugin e usado pelo(s) projetos(s) do Systêxtil que usarão o plugin.

Observe que o artefato gerado pelo plugin (arquivo .jar) nunca fica no classpath do código-fonte dos projetos, pois nunca é referenciado diretamente. Todas as chamadas são feitas através das classes da API.

5. Implantar o plugin

Os componentes que não são Java (arquivos de ajuda, leiautes de relatórios, scripts SQL, etc.) são implantados para uso pelo servidor JBoss ou pela aplicação Systêxtil 5 da maneira usual.

Os componentes Java são implantados em dois artefatos, dependendo do tipo:

Formulários em NXJ são implantados no artefato do tipo systextil-nomedoplugin-nxj.jar na pasta de plugins.
As outras classes Java (classes DAO, BO, DTO, batch, funções, leiautes JasperReports) são implantadas no artefato systextil-nomedoplugin.jar na pasta de plugins (ou shell).

Implantar a API de plugins atualizada

Não esquecer de atualizar também os artefatos systextil-plugins-api.jar na pasta deploy (ou shell) e systextil-plugins-nxj.jar na pasta de plugins.

6. Distribuir o plugin

Para oficializar as alterações no projeto systextil-plugins-api, é preciso fazer o build dele no Jenkins. Essas alterações ficam disponíveis imediatamente no Archiva interno, e serão publicadas para distribuição no Archiva externo automaticamente após o próximo build geral bem sucedido.

Para oficializar as alterações no plugin, basta fazer o build dele no Jenkins. Ele fica disponível imediatamente para distribuição no Archiva externo. Os plugins não são normalmente publicados no Archiva interno.

O SUM já está preparado para atualizar plugins nas instalações de clientes. Se o plugin estiver registrado para o cliente no cadastro de plugins da Systêxtil, o SUM baixa e instala os artefatos, e roda os scripts SQL e DDL do plugin.

Packages

Package

Description

systextil.bo.inte.sysplan

systextil.bo.inte.sysplan.configuration

systextil.bo.sintegra

Sintegra

systextil.erros

systextil.intg.dto

Classes DTO para uso em integrações no padrão oficial do ERP.

systextil.plugin.digisat

Digisat