Introdução

O Integrador de Componentes faz parte do FileNet Process Engine. Ele permite chamar funções de uma classe Java customizada a partir de uma etapa do componente em um fluxo de trabalho. Embora haja algumas limitações quanto aos tipos de dados que podem ser usados como argumentos para as funções, essa é uma poderosa maneira de incluir funcionalidade extra a um processo.

Neste tipo de cenário, você empacota a classe Java juntamente com suas classes dependentes em um arquivo jar e o configura para ser executado no contexto do Gerenciador de Componentes. O Gerenciador de Componentes é responsável por fornecer um ambiente "agradável" para a execução da classe Java. Como desenvolvedor da classe Java, é necessário conhecer a aparência e saber como configurar esse ambiente da melhor forma. A finalidade deste artigo é fornecer esse conhecimento.

Primeiro, o artigo aborda os princípios básicos de como obter sessões para o Process Engine e o Content Engine. Em seguida, descreve como depurar o código Java. Depois disso, você aprenderá sobre as opções de configuração. Finalmente, o artigo inclui uma discussão mais avançada sobre como desenvolver e configurar um módulo de login JAAS customizado para conectividade do banco de dados.

O código de origem

A seção Download contém um link para o código de origem que demonstra os conceitos apresentados neste artigo. O código inclui uma classe Java customizada com dois métodos públicos e uma classe de teste JUnit que contém o código para chamar os métodos. O método getFolderDocuments() demonstra o uso do Content Engine. O segundo método sendMailMessage() usa a conexão com o Process Engine para buscar a sessão de e-mail e enviar uma mensagem customizada usando um documento do Content Engine como modelo. O código de origem também inclui o módulo do código customizado descrito neste artigo.

Voltar para parte superior

Obtendo sessões

É possível usar componentes Java customizados para executar necessidades de negócios específicas que não são, de forma alguma, relacionadas ao sistema em si. No entanto, na prática, os componentes Java frequentemente têm de interagir com o Content Engine ou o Process Engine. Esta seção descreve como é possível obter sessões para os diferentes sistemas.

Uma explicação sobre sessões combinadas com o Integrador de Componentes geralmente começa com o fato de que a estrutura JAAS é usada para autenticação. Isso significa que a infraestrutura em torno do componente Java é responsável pelas conexões com os diferentes recursos, e o componente Java pode enfocar a funcionalidade específica desejada. Um dos objetivos deste artigo também é explicar como essa infraestrutura é preparada para o componente Java.

Quando você configura uma Fila de Componentes específica usando o Console de Configuração do Processo, é necessário fornecer um Contexto de Configuração na seção JAAS Credentials da guia Adaptor. Essa entrada de configuração é chamada de sub-rotina JAAS. O nome fornecido deve corresponder a uma entrada de configuração no arquivo taskman.login.config, localizado na pasta do Gerenciador de Componentes no Servidor de Aplicativos

Na prática, é necessário observar as diferentes conexões de que o componente Java precisa e configurar adequadamente a entrada de configuração. Se diferentes componentes Java precisarem das mesmas conexões, eles podem reutilizar um contexto de configuração existente.

Uma configuração mínima terá a seguinte aparência:

MyLoginContext 
{ 
	filenet.vw.server.VWLoginModule required; 
}; 

Na amostra de código acima, MyLoginContext é o nome do Contexto de Configuração. A terceira linha referencia o nome da classe Java do módulo de login. A seção Módulo de login customizado deste artigo trata mais elaboradamente do funcionamento interno dos módulos de login, mas, por enquanto, o principal a saber é que VWLoginModuleclass é obrigatória para todas as entradas de configuração. Sem essa linha, o gerenciador de componentes não pode iniciar o componente.

Esse módulo de login também é o provedor da sessão com o Process Engine. A sessão com o Process Engine é gerenciada pela classe VWSession . Essa classe tem um construtor específico que, de acordo com a documentação, pode ser usado "em um ambiente onde o contexto JAAS já está estabelecido". A assinatura desse construtor é:

public VWSession(java.lang.String url) throws VWException 

Isso poderia sugerir que deve ser fornecida uma URL como argumento, mas uma leitura adicional da documentação mostra que, na verdade, é necessário um ponto de conexão como argumento. Felizmente, o ponto de conexão está disponível como propriedade do sistema, por isso é possível usar o código a seguir para criar uma sessão com o Process Engine:

String connectionPoint = System.getProperty("filenet.pe.cm.connectionPoint"); 
VWSession vwsession = new VWSession( connectionPoint ); 

A manipulação de e-mail é uma das tarefas comuns executadas por um componente do Gerenciador de Componentes. Quando você configurar a notificação por e-mail no seu servidor do Process Engine, também será possível usar a sessão com o Process Engine para adquirir uma sessão com o seu provedor de serviços de e-mail, da seguinte forma:

javax.mail.Session mailSession = vwsession.createMailSession(); 

A fila de componentes padrão CE_Operations também fornece diversos métodos que podem ser usados para o envio de e-mails. No entanto, pode haver situações nas quais é necessário maior controle sobre a função de envio de mensagens.

Para obter uma sessão com o Content Engine, é necessário estender a configuração JAAS com um Módulo de Login extra copiado da entrada de configuração do FileNetP8, que também está presente no arquivo taskman.login.config. A nova entrada de configuração deve ter a seguinte aparência:

MyLoginContext
{
	filenet.vw.server.VWLoginModule required;
	com.filenet.api.util.WSILoginModule required debug=false;
};

A classe WSILoginModule estabelece uma conexão com o Content Engine usando as interfaces de serviço da Web. Conforme afirmado anteriormente, a infraestrutura em torno do componente é responsável pela conexão. Neste caso, classe WSILoginModule cria uma conexão com o Content Engine. Por isso, a única coisa que o componente precisa fazer é começar a usar a conexão.

Para criar uma nova conexão, é necessário ter uma URL (neste caso, trata-se realmente de uma URL) para o Content Engine. Felizmente, a URL está disponível como uma propriedade do sistema, por isso é possível usar o código a seguir para criar uma conexão com o Content Engine:

String url = System.getProperty("filenet.pe.bootstrap.ceuri"); 
Connection connection = Factory.Connection.getConnection(url); 

A partir deste ponto, é possível buscar um Armazenamento de Objeto e executar trabalho real do Content Engine, como no exemplo a seguir:

EntireNetwork entireNetwork = Factory.EntireNetwork.fetchInstance(connection, null); 
Domain domain = entireNetwork.get_LocalDomain(); 
ObjectStore objectStore = Factory.ObjectStore.getInstance( domain, "MyOS" ); 

Voltar para parte superior

Depurando componentes

Dois fatores podem tornar desafiadores a depuração e o teste de componentes Java desenvolvidos para o Integrador de Conteúdo. Primeiramente, os componentes são totalmente gerenciados pelo Gerenciador de Componentes. Por isso, é difícil gerenciar seu ambiente de tempo de execução, e isso dificulta os testes e a depuração. O segundo fator é que é necessário chamar o componente a partir de uma etapa do componente em um fluxo de trabalho, e isso exige que você crie um processo de teste e inicie esse processo toda vez que executar etapas de teste.

Uma maneira de lidar com esse ambiente é trazê-lo de volta ao IDE. O artigo "Develop FileNet P8 BPM 4.0 custom components using Eclipse" (consulte a seção Recursos para obter o link) descreve como é possível configurar o Eclipse para Executar o Gerenciador de Componentes dentro do IDE. Isso aborda o primeiro fator desafiador descrito acima, mas não elimina os desafios apresentados pelo segundo fator.

Uma abordagem para tratar do segundo desafio é abrir o componente Java para testes e depuração usando o padrão de design do modelo. A ideia é quebrar cada referência para uma sessão em uma função pública ou protegida. Dessa forma, o código para obter uma sessão com o Content Engine tem a seguinte aparência:

protected Connection getConnection() { 
   String uri = System.getProperty("filenet.pe.bootstrap.ceuri"); 
   return Factory.Connection.getConnection(uri); 
} 
... 

Connection connection = getConnection(); 

Essa mudança tem pequeno ou nenhum impacto no componente Java em execução, mas abre o componente para testes. Para testar o componente, primeiro crie um programa de testes que se conecta ao Content Engine. Por exemplo, é possível usar um código semelhante ao seguinte:

private static Connection connection; 

@BeforeClass 
public static void setUpBeforeClass() throws Exception { 
   // initialize connection parameters 
   ... 
   connection = Factory.Connection.getConnection(url); 
   Subject subject = UserContext.createSubject(connection, username, password, 
								"FileNetP8"); 
   UserContext uc = UserContext.get(); 
   uc.pushSubject(subject); 
} 

No exemplo acima, a conexão é armazenada como um campo de uma classe de testes JUnit e inicializada no método setUpBeforeClass() . A próxima etapa é criar uma nova instância do componente Java usando um construtor semelhante ao seguinte:

MyOperations myOperations = new MyOperations () { 
   protected Connection getConnection() { 
      return connection; 
   } 
}; 

Criando a nova classe dessa forma, você substitui o método getConnection() existente, que serve como um método modelo para a conexão. Agora, você tem total controle sobre o componente Java, e não precisa mais do gerenciador de componentes para executar o componente. Por isso, não é mais necessário chamar o componente Java a partir de uma etapa do componente em um fluxo de trabalho, o que soluciona o segundo desafio mencionado anteriormente.

É possível usar um método semelhante para quebrar a sessão para o Process Engine em um modelo. No componente Java, quebre a criação de VWSession em uma função, da seguinte maneira:

protected VWSession getVWSession() throws VWException { 
String connectionPoint = System.getProperty("filenet.pe.cm.connectionPoint"); 
return new VWSession(connectionPoint); 
} 

O programa de testes usa a seguinte conexão para conectar-se ao Process Engine e usa um construtor para substituir a função getVWSession() e retornar a instância da classe VWSession para a função:

private static VWSession vwSession; 
... 
vwSession = new VWSession(); 
vwSession.setBootstrapCEURI(url); 
vwSession.logon( username, password, connectionPointName ); 
... 
MyOperations myOperations = new MyOperations () { 


VWSession getVWSession() throws VWException { 
return vwsession; 
} 
}; 

Os tipos de dados primitivos Java, como cadeia de caractere, operadores booleanos e número inteiro podem ser fornecidos diretamente do programa de testes para o método que está sendo testado. Existem dois tipos de dados que também são suportados como argumentos para as funções da classe Java: VWAttachment e VWParticipant. Para esses dois tipos de dados, é necessária uma função de utilitário para converter os dados do teste no tipo de dados apropriado. Por exemplo, é possível usar o código a seguir para converter um objeto de pasta do Content Engine em uma classe VWAttachment :

private VWAttachment getFolderAsVWAttachment(Folder folder) throws VWException { 
   VWAttachment folderAttachment = getCEAttachment(folder.getObjectStore() ); 
   folder.fetchProperties( new String[] { PropertyNames.ID, PropertyNames.NAME } ); 
   folderAttachment.setId( folder.get_Id().toString() ); 
   folderAttachment.setAttachmentName( folder.get_Name() ); 
   folderAttachment.setType( VWAttachmentType.ATTACHMENT_TYPE_FOLDER ); 
   return folderAttachment; 
} 
private VWAttachment getCEAttachment(ObjectStore objectStore) throws VWException { 
   VWAttachment ceAttachment = new VWAttachment(); 
   ceAttachment.setLibraryType( VWLibraryType.LIBRARY_TYPE_CONTENT_ENGINE ); 
   objectStore.fetchProperties( new String[] { PropertyNames.NAME } ); 
   ceAttachment.setLibraryName( objectStore.get_Name() ); 
   return ceAttachment; 
} 

O desenvolvimento de um componente usando o método descrito nesta seção de fato causa um pequeno problema que precisa ser solucionado. Quando você configura uma classe Java usando o Console de Configuração do Processo, encontra o seguinte erro no console Java do applet ao recuperar os métodos públicos da classe:

java.lang.NoClassDefFoundError: com/filenet/api/core/Connection 
	at java.lang.Class.getDeclaredMethods0(Native Method) 
	at java.lang.Class.privateGetDeclaredMethods(Unknown Source) 
	at java.lang.Class.getDeclaredMethods(Unknown Source) 
	at filenet.vw.integrator.adaptors.java.VWJavaBaseDialog.initMethodList 
(VWJavaBaseDialog.java:224) 	
	(...) 

Devido a essa exceção, nenhum dos métodos públicos da classe é mostrado. Esse erro é causado pelo método getConnection() incluído anteriormente. A classe de retorno desse método não é uma classe reconhecida e, por isso, o método getDeclaredMethods() falha. Esse problema ocorre toda vez que um método é incluído na classe Java usando tipos de dados "de terceiros" como argumentos de método ou valores de retorno. A solução é usar o Console de Configuração do Processo para registrar os arquivos jar que contêm essas classes. No console, abra a região isolada, selecione o ícone de pasta Component Queues e o comando Register additional classes no menu Action. Em seguida, inclua o arquivo jar que, neste caso, é o arquivo jar que contém a API do Content Engine (Jace.jar). Finalmente, confirme a mudança para o Process Engine.

Voltar para parte superior

Configuração

Pode ser necessário realizar mudanças de configuração adicionais na classe Java, além das mudanças para as conexões com os diferentes sistemas. Para fazer essas modificações na configuração do Gerenciador de Componentes, use o Gerenciador de Tarefas do Processo do seu servidor de aplicativos. Use o campo JRE parameters na guia Advanced da configuração para definir propriedades adicionais. Com esse campo, é possível especificar o valor de propriedades específicas ou um caminho para um arquivo de configuração. É possível usar a função System.getProperty() para recuperar o valor das propriedades configuradas.

Também é possível especificar a localização do arquivo de configuração log4j como um parâmetro JRE. Para fazer isso, inclua a seguinte linha nos parâmetros existentes:

-Dlog4j.configuration=file:C:\Program Files\MyComponent\log4j.properties 

Agora, é possível incluir o registro de log nos componentes Java com um simples arquivo de configuração log4j.properties como o seguinte:

log4j.appender.MyAppender=org.apache.log4j.RollingFileAppender 
log4j.appender.MyAppender.File=C:/Program Files/MyComponent/trace.log 
log4j.appender.MyAppender.layout=org.apache.log4j.PatternLayout 
log4j.appender.MyAppender.layout.ConversionPattern=%d %5p [%t] -%m\r\n 

log4j.category.mypackage.MyOperations=debug, MyAppender 

No exemplo acima, RollingFileAppender evita que o sistema de arquivos seja preenchido. A parte [%t] da configuração ConversionPattern é útil se seu Gerenciador de Componentes estiver executando mais de um encadeamento para uma fila de componentes específica. O [%t] serve para tornar claro qual encadeamento está registrando uma mensagem específica.

Também é possível usar os parâmetros JRE para ativar o Gerenciador de Componentes para depuração remota. Esse tipo de depuração é semelhante ao descrito no artigo do developerWorks "Develop FileNet P8 BPM 4.0 custom components using Eclipse" (consulte a seção Recursos para obter o link). Em vez de trazer o Gerenciador de Componentes para o seu IDE, conecte o IDE ao Gerenciador de Componentes em execução remota. Para ativar a depuração remota, inclua os seguintes parâmetros nos parâmetros existentes:

-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n 

Se você estiver usando o Eclipse como IDE, é necessário usar as configurações de ativação de um "Aplicativo Java Remoto" para fazer uma nova Configuração de Depuração para o projeto. Configure o host para o servidor de aplicativos que está executando o componente Java. Em seguida, é possível começar a depuração iniciando a Configuração de Depuração que você criou. Quando a depuração for concluída, é possível desconectar o IDE usando a ação Disconnect.

Voltar para parte superior

Módulo de login customizado

Às vezes, uma classe Java pode precisar interagir com um banco de dados. Uma forma de ativar um cenário desse tipo é recuperar as configurações necessárias para conexão com o banco de dados a partir de um arquivo de configuração. Geralmente, o arquivo de configuração contém as credenciais do usuário que está acessando o banco de dados. O método mostrado nesta seção usa a estrutura JAAS para conectar-se a um banco de dados. O usuário que está acessando o banco de dados é o mesmo usuário configurado para acessar os outros sistemas. Dessa forma, não é necessário um arquivo de configuração específico que contenha as credenciais. Para fazer isso, é necessário usar um módulo de login customizado. Esta seção descreve como escrever e implementar esse tipo de módulo de login. O artigo "JAAS LoginModule Developer's Guide" no developerWorks (consulte a seção Recursos para obter o link) fornece boas informações gerais sobre a composição de módulos de login customizados.

Um módulo de login customizado deve implementar a interface javax.security.auth.spi.LoginModule . Essa interface tem a seguinte aparência:

public interface LoginModule { 
  void initialize(Subject subject, CallbackHandler callbackhandler, Map sharedState, 
			Map options); 
  boolean login() throws LoginException; 
  boolean commit() throws LoginException; 
  boolean abort() throws LoginException; 
  boolean logout() throws LoginException; 
} 

Os métodos da interface são chamados de acordo com o andamento do processo de autenticação. O método initialize() sempre é chamado primeiro. Esse é o método onde o módulo de login pode salvar os dados necessários para o restante do processo de autenticação nos campos das suas classes. Aqui está o método initialize() usado para esse exemplo:

public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, 
				Map options) { 
  this.subject = subject; 
  this.sharedState = sharedState; 

  driverClass = (String) options.get( "driverClass"); 
  connectionUrl = (String) options.get( "connectionUrl" ); 
} 

O método initialize() mostrado acima salva a referência de campo de uma classe para os parâmetros subject esharedState . Os valores de driverClass e connectionUrl são lidos no mapa de opções. A maneira pela qual os valores são configurados será discutida posteriormente. Para este exemplo, o restante dos parâmetros do método não é relevante.

Aqui está o método login() usado para esse exemplo:

public boolean login() throws LoginException {
   succeeded = false;
   getCredentials();
   createDatabaseConnection();
   succeeded = true;
   return succeeded;
}

Tipicamente, a função login() executa três tarefas:

• Obtém as credenciais do usuário
• Usa as credenciais para executar a autenticação desejada
• Gerencia um parâmetro booleano que indica o resultado da função de login

Para este exemplo, o código a seguir é usado para obter as credencias:

private void getCredentials() throws LoginException {
   username = (String) sharedState.get("javax.security.auth.login.name");
   password = (String) sharedState.get("javax.security.auth.login.password");
}

O módulo de login customizado explora os benefícios do compartilhamento de credenciais. A classe VWLoginModule , que está mais acima no processo de autenticação, já usou o mecanismo de retorno de chamada do JAAS para adquirir o nome de usuário e a senha e armazenou essas informações no mapa de estado compartilhado. Por isso, tudo o que o método precisa fazer é ler esses valores no mapa de estado. O artigo "JAAS LoginModule Developer's Guide" (consulte a seção Recursos para obter o link) descreve os nomes de chave javax.security.auth.login.name e javax.security.auth.login.password como a convenção padrão para armazenar essas informações.

Agora, conforme mostrado no código a seguir, todas as informações necessárias estão disponíveis para a realização da conexão com o banco de dados:

private Connection createDatabaseConnection() throws LoginException {
   try {
      Class.forName( driverClass );
      connection = DriverManager.getConnection(connectionUrl, username, password);
      return connection;
   } catch (Exception exception ) {
      throw new LoginException( exception.getLocalizedMessage() );
    }
}

O método de login deve sempre lançar uma LoginException se houver um erro durante o processo de autenticação. Por isso, o método anterior quebra a exceção em uma classe LoginException .

Se o método de login for bem-sucedido, a maneira pela qual o restante do processo de autenticação prossegue depende do resultado dos outros módulos de login envolvidos no processo de autenticação. Se todos os módulos de login forem concluídos, a segunda fase do processo de autenticação será iniciada. Com base na configuração, se todos os módulos de login necessários, suficientes e opcionais fornecerem resultados satisfatórios, como mostrado no código a seguir, o método commit() será chamado:

public boolean commit() throws LoginException {
   if ( succeeded ) {
      registerPrincipal();
      clearCredentials();
      commitSucceeded = true;
      return true;
   }
   return false;
}

A especificação de interface declara que, se esse método for chamado quando o método login() for bem-sucedido, ele deve retornar um valor de false. Se o login() for bem-sucedido, esse método deve armazenar o resultado do processo de autenticação no objeto Subject que é passado na inicialização.

A classe javax.security.auth.Subject representa o objeto que está sendo autenticado. Após a conclusão do processo de autenticação, a instância é associada às diferentes identidades que o objeto possui. A conexão com o Process Engine é uma das identidades obtidas pelo objeto durante o processo de autenticação. Esse módulo de login customizado inclui outra identidade, a conexão com o banco de dados. As identidades são representadas por classes implementando as interfaces java.security.Principal e java.io.Serializable . A interface java.security.Principal tem a seguinte aparência:

   public interface Principal {
   boolean equals(Object another);
   String getName();
   int hashCode();
   String toString();
}

Para este exemplo, a classe DatabasePrincipal implementa as interfaces necessárias. A parte de implementação das interfaces é bastante simples e, por isso, não é mostrada aqui. A parte interessante da classe é a seguinte:

public class DatabasePrincipal implements Principal, Serializable {
   private String name;
   private Connection connection;

   public DatabasePrincipal(String username, Connection connection) {
      this.name = username;
      this.connection = connection;
   }
   public Connection getConnection() {
      return connection;
   }
   // Some more code, see attached source code
}

A classe contém uma referência para a conexão com o banco de dados como um campo de classe e também fornece um método "getter" para essa conexão. Os clientes que obtêm essa identidade podem usar essa conexão para interagir com o banco de dados.

A alternância para o método commit() fornece a seguinte implementação do método registerPrincipal() :

private void registerPrincipal() throws LoginException {
   principal = new DatabasePrincipal( username, connection );
   if ( !subject.getPrincipals().contains(principal) ) {
      subject.getPrincipals().add(principal);
   }
}

O método acima cria uma nova instância da classe DatabasePrincipal usando o nome de usuário e a conexão com o banco de dados. Em seguida, ele inclui essa instância na coleção de principais. A implementação dos métodos abort() e logout() não é mostrada. Para ver esses métodos e o restante do módulo de login, é possível consultar a amostra do código de origem incluída na seção Download .

Para usar a classe DatabasePrincipal em um programa cliente, é necessário primeiro configurá-la e implementá-la. No início desta seção, os parâmetros driverClass econnectionUrl foram lidos no mapa de opções. O mapa de opções é preenchido a partir do arquivo de configuração do JAAS. Para o módulo desse código, a linha de configuração do JAAS deve ter o seguinte aspecto (uma configuração de depuração extra também foi incluída):

mypackage.database.DatabaseLoginModule required debug="true"
connectionUrl="jdbc:sqlserver://localhost:1433;DatabaseName=MYDB;integratedSecurity=tr
ue;" driverClass="com.microsoft.sqlserver.jdbc.SQLServerDriver";

No exemplo acima, o módulo de login customizado faz parte do componente Java que o utiliza. Por isso, a implementação do componente Java também implementa o módulo de login no gerenciador de componentes. Também é necessário incluir o driver JDBC do banco de dados como uma biblioteca necessária do gerenciador de componentes.

As credenciais do usuário configurado no Gerenciador de Componentes são usadas para estabelecer conexão com o banco de dados. Esse usuário deve ter direitos suficientes para acessar o banco de dados. A senha usada para estabelecer conexão com o banco de dados deve ser igual à senha configurada; caso contrário, será necessário configurar a conexão para usar um esquema de segurança integrado.

No componente Java que estiver utilizando o módulo de login do banco de dados, use o código a seguir para recuperar a instância da classe DatabasePrincipal e, subsequentemente, a conexão com o banco de dados:

protected java.sql.Connection getDatabaseConnection() {
   Subject subject = Subject.getSubject( AccessController.getContext() );
   Set<DatabasePrincipal> principals = subject.getPrincipals( DatabasePrincipal.class );
   if ( principals != null && ! principals.isEmpty() ) {
      DatabasePrincipal principal = principals.iterator().next();
      return principal.getConnection();
   }
   return null;
}

Voltar para parte superior

Conclusão

Este artigo descreveu como desenvolver e depurar um componente Java customizado para ser usado com o Integrador de Componentes FileNet. Esse método de depuração reduz o tempo necessário para desenvolver o componente e possibilita testar facilmente o componente usando etapas de teste JUnit. O método também pode alterar a forma como você normalmente desenvolve esse tipo de componente. Usando o método tradicional, é necessário testar o componente que você está desenvolvendo configurando e implementando -o rapidamente no Process Engine. Toda vez que você altera a estrutura do componente, é necessário reconfigurar e reimplementá-lo para o teste. Usando as técnicas descritas neste artigo, é possível primeiro projetar e testar inteiramente o componente e minimizar o esforço necessário para a reconfiguração e reimplementação.

A segunda parte do artigo descreveu como desenvolver um módulo de login customizado, o que é necessário caso o componente tenha que estabelecer conexão com sistemas externos. As informações desta seção também podem ser usadas para escrever módulos de login adicionais.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• "Develop FileNet P8 BPM 4.0 custom components using Eclipse" (developerWorks, agosto de 2008) fornece informações sobre o desenvolvimento de componentes customizados para o FileNet.
  
  
• O artigo Java Authentication and Authorization Service (JAAS) 2.0, Guia do Desenvolvedor do Módulo de Login , no developerWorks, fornece detalhes sobre escrever um módulo de login implementando a tecnologia de autenticação.
  
  
• O artigo "Building the Connection URL" no Web site da Biblioteca MSDN explica como desenvolver uma URL de conexão para o SQL Server.
  
  
• A Área de ECM do developerWorks fornece os recursos necessários para melhorar suas qualificações no FileNet e em outros produtos do IBM Enterprise Content Management.
  
  

Obter produtos e tecnologias

• Faça o download das versões de avaliação de produto IBM ou explore as versões de teste on-line no IBM SOA Sandbox e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2 ®, Lotus®, Rational®, Tivoli® e WebSphere®.
  
  

Discutir

• Confira os blogs do developerWorks e participe da comunidade do developerWorks.
  
  

Sobre o autor

Ricardo Belfor vive e trabalha na Holanda. Desde 1996, ele trabalha como arquiteto e programador para empresas especializadas na implementação de sistemas FileNet. Ele projetou e desenvolveu sistemas FileNet para várias grandes organizações na Holanda usando diversos produtos e linguagens de programação FileNet.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Obtendo sessões
• Depurando componentes
• Configuração
• Módulo de login customizado
• Conclusão
• Download
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais