Introdução

O IBM InfoSphere Guardium Data Redaction suporta a divulgação de informações em documentos. O servidor de edição de dados remove automaticamente as informações privadas em documentos e formulários de texto livre, como mostrado na Figura 1.

Essas funções ajudam a processar números grandes de documentos que podem estar espalhados em vários locais. Onde há requisitos reguladores ou necessidades de negócios para manter a privacidade de determinadas informações nos documentos, ao revelar especificamente informações relevantes às pessoas autorizadas, o sistema de edição de dados pode ajudar a satisfazer ambos os objetivos.

Esse produto inclui aplicativos baseados em navegador com interfaces intuitivas que permitem redigir documentos ou visualizar os documentos redigidos. Além disso, oferece várias opções de acesso automatizadas. Esses recursos podem ser especialmente valiosos em fluxos de trabalho do Enterprise Content Management (ECM), onde a edição de dados controlada é uma parte essencial do gerenciamento de documento.

Há três métodos para usar esses serviços de edição de dados:

• Por meio dos repositórios de documento ou de um sistema de arquivo. Você copia os documentos originais em uma pasta de entrada e recebe os arquivos redigidos em uma pasta de saída.
• Por meio da API SOAP, recomendado para aplicativos não Java.
• Por meio da API do cliente de edição de dados Java, o foco deste artigo.

O IBM InfoSphere Guardium Data Redaction fornece uma API do cliente de edição de dados de modo que os aplicativos clientes podem controlar diretamente o serviço de edição de dados por meio da API. Este artigo descreve os recursos da API do cliente de edição de dados e como usar a API em um aplicativo customizado. Três cenários típicos estão descritos com exemplo neste artigo.

Observação: Este artigo se baseia no IBM InfoSphere Guardium Data Redaction V2.1.

Voltar para parte superior

API do Cliente de Edição de Dados

A API do cliente de edição de dados é uma biblioteca da classe Java para acessar os serviços do servidor de edição de dados de um programa. O kit de ferramentas da API está incluída com o IBM InfoSphere Guardium Data Redaction.

O código de amostra e documentação prontos para uso são fornecidos para as APIs. Quando o produto é instalado, as bibliotecas da API e um programa de amostra são copiados para a pasta <IBM_REDACTION_HOME>\client, onde <IBM_REDACTION_HOME> é a pasta de instalação. O documento Java da API também é copiado para a pasta <IBM_REDACTION_HOME>\docs\apidocs.

Há dois modos de usar o serviço de edição de dados de um aplicativo customizado com a API: um modo de cliente remoto e um modo de cliente em processo. No modo de cliente remoto, um programa em uma máquina cliente remota (ou local) chama o servidor de edição de dados por meio de uma conexão SOAP. No modo do cliente em processo, o servidor inteiro de edição de dados executa com parte do aplicativo cliente. A implementação do programa é praticamente a mesma em ambos os modos. Nesses exemplos, o uso da API no modo do cliente remoto é mostrado primeiro para cada um dos três cenários típicos. Finalmente, as diferenças entre os modos estão descritos.

O primeiro cenário é o mais básico. Um programa cliente simplesmente conecta-se ao servidor e redige um documento. No segundo cenário, muitos documentos são enviados ao servidor e são redigidos usando um repositório em lote. O terceiro cenário é um caso avançado mostrando o alto nível de controle que um aplicativo tem sobre a edição de dados de uma coleta de documentos.

Voltar para parte superior

Cenário 1: Edição de Dados do Sistema de Arquivo Normal

Este é o cenário mais simples e ilustra o uso básico da AP. Neste cenário, um programa em uma máquina cliente remota envia uma solicitação de edição de dados ao servidor de edição de dados, como mostrado na Figura 2.

O cenário envolve estas etapas:

1. Estabelecer uma conexão ao servidor de edição de dados
2. Carregar um documento de destino como dado binário
3. Submeter uma solicitação de edição de dados
4. Salvar o resultado como um documento

Estabelecer Conexão ao Servidor de Edição de Dados

Para conectar ao servidor de edição de dados, primeiro crie um objeto de classe RedactionToolkitClient. O método createRemoteClient() é usado para criar o objeto no modo de cliente remoto. A Listagem 1 mostra um exemplo de como usar o método createRemoteClient().

User user = new User("CustomApp01", "userid", "password");
RedactionToolkitClient client = RedactionToolkitClient.createRemoteClient("foo.bar.com", 
8097, user);

Quando o método createRemoteClient() é chamado, uma conexão SOAP entre a máquina cliente remota e o servidor de edição de dados é estabelecida. Portanto, o método requer o endereço IP e o número da porta do servidor de edição de dados. Também requer um ID do usuário e senha válidos para o servidor de edição de dados. Assim que o servidor de edição de dados e o cliente estão conectados, seu aplicativo pode chamar os serviços do servidor por meio do mecanismo SOAP. A API fornece vários métodos para chamar os serviços de edição de dados.

Carregar um Documento de Destino como Dados Binários

O servidor de edição de dados suporta vários formatos de documentos como PDF, Microsoft Word, imagens tiff e texto simples. Para todos os formatos, o conteúdo do documento deve ser passado para o servidor como um array binário. Portanto, os arquivos devem ser abertos no modo binário ao redigir documentos em um sistema de arquivos.

Submeter uma Solicitação de Edição de Dados

O método redactDocumentByRules() envia uma solicitação de edição de dados ao servidor. Esse método requer vários parâmetros para especificar as opções para a solicitação. A Tabela 1 abaixo lista as classes que são usadas para especificar os parâmetros da solicitação.

A classe RedactionAttributes especifica como redigir o documento. A Listagem 2 mostra como configurar os atributos de edição de dados para esse objeto de classe. Nesta amostra, “image/png” é especificado com o tipo de conteúdo de saída, GRAY como o modo de cor de saída e "Classified" como o registro no canto superior esquerdo das páginas de documento. A RedactionAttributes.ColorMode.GRAY é uma constante estática para especificar o modo de cor.

// Set Redaction Attributes
// Set output format
RedactionAttributes redactionAttributes = new RedactionAttributes("image/png");
// Set color mode
redactionAttributes.addAttribute(RedactionAttributes.ColorMode.COLOR_MODE ,
new AttributeValue(RedactionAttributes.ColorMode.GRAY.toString()));
// Set stamp
RedactionStamp stamp = new RedactionStamp(Boolean.TRUE, "Classified",
RedactionStamp.StampPosition.UPPER_LEFT) ;
redactionAttributes.addRedactionStamp(stamp);

O objeto de classe Document é usado para configurar as informações sobre o documento de entrada e obter as informações no documento redigido. A classe DocumentAttributes é usada para manter os metadados da classe Document, como nome do documento, tipo de conteúdo, idioma e outros.

Na Listagem 3, o nome e o tipo de conteúdo do documento de entrada são especificados pelo desenvolvedor. Quando "" é especificado como o tipo de conteúdo, o servidor de edição de dados examina os dados do documento e identifica o tipo. O idioma do documento (inglês) é configurado para o objeto usando o método addAttribute(). Se o idioma não for especificado, o sistema o identificará automaticamente durante o processo de edição de dados. Os dados binários do documento, a instância documentAttributes e o status do documento são definidos no objeto de classe Document. Nesse código de amostra, os dados binários do documento são armazenados na variável inputDocBytes .

byte[] inputDocBytes; //  binary document data
...
// set file name and language
DocumentAttributes documentAttributes = new DocumentAttributes("sales_results.pdf", "",
null);
documentAttributes.addAttribute(DocumentAttributes.LANGUAGE, new AttributeValue("en"));
// set binary data, attributes and status
Document document = new Document(inputDocBytes, documentAttributes,
DOCUMENT_STATE.NOT_REDACTED);

O IBM InfoSphere Guardium Data Redaction tem 13 categorias semânticas principais predefinidas, como mostrado na Tabela 2, de modo que é possível especificar que palavras devem ser redigidas nos documentos. É possível criar categorias adicionais, conforme for necessário.

Quando uma solicitação de edição de dados é enviada para o servidor usando o método redactDocumentByRules(), os tipos de dados de destino para edição de dados são especificados. A Listagem 4 mostra um exemplo de como preparar as regras de edição de dados e chamar o método. Este exemplo especifica que o número de telefone, nome pessoal e endereço devem ser redigidos.

RedactionRules rules = new RedactionRules();
rules.add(new RedactionRule( 2, RedactionRule.PERMISSION_TYPE.REDACT)); // ID  2:
Phone Number
rules.add(new RedactionRule(10, RedactionRule.PERMISSION_TYPE.REDACT)); // ID 10:
Person name
rules.add(new RedactionRule(11, RedactionRule.PERMISSION_TYPE.REDACT)); // ID 11: Address
Document outDocument = client.redactDocumentByRules(redactionAttributes, document, rules);

Os tipos de dados para edição de dados podem ser mais facilmente especificados usando regras. As permissões das diversas categorias semânticas (como se redigir ou não) são especificadas para cada função. Juntas, as regras e funções são chamadas modelo de política, que deve ser definido em um arquivo XmlPolicyModel.xml na pasta <IBM_REDACTION_HOME>\server\conf no servidor de edição de dados.

O método redactDocumentForRole() é usado para especificar a função como uma opção de edição de dados. A Listagem 5 mostra um exemplo de como usar o método redactDocumentForRole(). A função RESTRICTED (ID 1000) é uma das funções de amostra do produto. Normalmente, você deve definir suas próprias funções que adaptam sua lógica de negócios com as categorias semânticas predefinidas.

int ROLE_RESTRICTED = 1000; // RESTRICTED role in the sample policy model
// redact a document
Document outDocument = client.redactDocumentForRole(redactionAttributes, document,
ROLE_RESTRICTED);

Salvar o Resultado como um Documento

Ambos os métodos, redactDocumentByRules() e redactDocumentForRole(), retornam um objeto de classe Document como o resultado redigido. Os dados binários e o nome do documento desse objeto são usados para salvar o documento para um arquivo local.

Esse cenário é melhor para clientes que requerem processamento síncrono. A conexão para o servidor de edição de dados é mantida ativa até o final da edição de dados. Isso permite que clientes rastreiem o progresso e controlem a execução de edições de dados. Os parâmetros de edição de dados são passados com cada documento individual. Para obter um rendimento melhor, os clientes podem submeter solicitações de vários encadeamentos. O segundo cenário é adequado para a edição de dados de números grandes de documentos quando o aplicativo cliente não deve ser bloqueado.

Voltar para parte superior

Cenário 2: Redigir Documentos em um Repositório em Lote

Um repositório é uma pasta especificada, incluindo subpastas, em um sistema de arquivo ou em um sistema ECM. É usado para documentos de entrada e de saída, além de outros artefatos usados na edição de dados. Há dois tipos de repositórios: lote e on demand. Um repositório em lote é usado nesse segundo cenário. O servidor de edição de dados é configurado para monitorar a pasta de entrada do repositório em lote para documentos de entrada. Quando documentos são copiados à pasta de entrada, o servidor inicia automaticamente para redigir documentos com as opções definidas antecipadamente para o repositório e coloca os resultados na pasta de saída.

Nesse cenário, o aplicativo customizado é dividido em duas partes, como mostrado na Figura 3. A primeira parte, o aplicativo customizado A, simplesmente envia os documentos ao repositório em lote. Depois de o servidor ter processado os documentos, a segunda parte, o aplicativo customizado B, conecta-se ao servidor e faz download dos documentos redigidos.

A Tabela 3 mostra os métodos relacionados ao repositório da classe RedactionToolkitClient . Esse cenário é implementado usando alguns desses métodos.

Enviar os Documentos

O aplicativo customizado A se conecta ao servidor e carrega os documentos de destino. Essas operações são similares às primeiras duas etapas no Cenário 1.

O método addDocumentToRepository() coloca um documento na pasta de entrada do repositório especificado. A Listagem 6 mostra um exemplo de como usar o método addDocumentToRepository(). O "lote" é o nome de um dos repositórios em lote de amostra que é criado quando o produto está instalado.

DocumentAttributes documentAttributes = new DocumentAttributes("sales_results.pdf", "",
null);
Document document = new Document(inputDocBytes, documentAttributes,
DOCUMENT_STATE.NOT_REDACTED);
client.addDocumentToRepository(document, "batch");

O aplicativo continua o upload até que todos os documentos sejam enviados ao repositório. Quando o último documento foi transferido por upload, o programa termina.

O servidor está monitorando a pasta de entrada e inicia automaticamente para processar os documentos. Isso torna desnecessário manter uma conexão ao servidor durante o processamento. Os documentos são processados com as opções que estão definidas no arquivo de configuração que está armazenado no servidor de edição de dados para esse repositório.

Fazer Download dos Documentos e Limpar o Repositório

Posteriormente, o aplicativo customizado B se conecta ao servidor de edição de dados e verifica a pasta de saída do repositório. O método queryDocumentRepository() obtém referências para os documentos no repositório especificado. A Listagem 7 mostra um exemplo de como usar o método queryDocumentRepository().

String repositoryFolderName = "batch";
DocumentReference[] docRefs = null;
...
docRefs = client.queryDocumentRepository(new DocumentRepositorySearchCriteria
(repositoryFolderName, DocumentRepositorySearchCriteria.SEARCH_WITHIN.REDACTED));

Para localizar os documentos redigidos, DocumentRepositorySearchCriteria.SEARCH_WITHIN.REDACTED deve ser especificado como o tipo dos documentos pelos quais pesquisar, o que significa que documentos foram redigidos em vez dos documentos originais. Os resultados da consulta são retornados em um array da classe DocumentReference . As referências são usadas para especificar documentos nas pastas de repositório a serem transferidas por download ou excluídas. O método getRepositoryDocument() obtém os dados reais do documento, o objeto de classe Document. Mesmo depois de serem transferidos, os dados originais ainda permanecem no repositório. O método deleteRepositoryDocument() é chamado para limpar o repositório. A Listagem 8 mostra um exemplo de como usar os métodos getRepositoryDocument() e deleteRepositoryDocument() .

for (int i = 0; i < docRefs.length; i++) {
    Document doc = client.getRepositoryDocument(docRefs[i]);
    ...
    // save the binary data to a local file
    ...
    // delete the document to ensure next query doesn't return it
    client.deleteRepositoryDocument(docRefs[i]);
}

Um repositório em lote é designado para redigir muitos documentos de uma vez por um número configurável de encadeamentos. Um conjunto de opções de edição de dados, por exemplo, o formato de saída, modo de cor, função e outros, pode ser especificado para cada repositório. Se houver opções de edição de dados diferentes para documentos diferentes, um repositório em lote deverá ser preparado para cada conjunto de opções. Em contraste, com um repositório on demand, é possível controlar como o servidor redige cada documento no repositório.

Voltar para parte superior

Cenário 3: Redigir Documentos com um Repositório On Demand

No terceiro cenário, o aplicativo customizado está dividido em três partes. As partes upload e download são quase as mesmas que as do segundo cenário, exceto que os documentos são colocados em um repositório on demand. Diferente do repositório em lote, o repositório on demand não inicia para redigir o documento de entrada automaticamente. Portanto, uma nova parte, o aplicativo customizado C, deve estar executando na máquina do servidor para solicitar que o servidor processe os documentos, como mostrado na Figura 4.

O aplicativo customizado A faz upload dos documentos para o repositório on demand. Isso pode ser feito repetidamente e de acordo com a necessidade. O aplicativo customizado C na máquina do servidor executa em um planejamento regular, por exemplo, uma vez por dia, quando verifica o repositório para localizar os documentos.

O aplicativo C está executando na máquina do servidor, contudo ele ainda se conecta ao processo do servidor por meio de uma conexão SOAP porque createRemoteClient() é usado como em outros aplicativos customizados. As referências dos documentos na pasta de entrada do repositório são obtidos usando o método queryDocumentRepository() com a opção DocumentRepositorySearchCriteria.SEARCH_WITHIN.NOT_REDACTED. O método redactRepositoryDocumentByRules() ou redactRepositoryDocumentForRole() é usado para redigir os documentos nas pastas de repositório on demand.

O aplicativo pode especificar opções diferentes para cada documento usando a classe RedactionAttributes e as funções ou regras requeridas pela lógica de negócios. Por exemplo, regras diferentes podem ser especificadas para cada documento referindo-se a cada nome de documento.

A Listagem 9 mostra um exemplo de como usar o redactRepositoryDocumentForRole(). Nesse código, documentos cujo prefixo de nome de arquivo seja “ClassA” são redigidos com a função RESTRICED e o registro “Classified” é incluído nas páginas.

for (int i = 0; i < docRefs.length; i++) {
    // Set output format
    int role = 1001; //  GENERAL role in the sample policy model
    RedactionAttributes redactionAttributes = new RedactionAttributes("image/tiff"); //
set output format to tiff image

    if(docRefs[i].getDocumentName().startsWith("ClassA")){
        //add stamp and use RESTRICTED role
        RedactionStamp stamp = new RedactionStamp(Boolean.TRUE, "Classified",
RedactionStamp.StampPosition.UPPER_LEFT) ;
        redactionAttributes.addRedactionStamp(stamp);
        role = 1000; //  RESTRICTED role in the sample policy model
    }
    client.redactRepositoryDocumentForRole(redactionAttributes, docRefs[i], role);
}

Este cenário pode ser estendido para integrar o processo de edição de dados do documento no fluxo de trabalho do documento, como necessário. O servidor de edição de dados pode acessar um sistema ECM e usa seu armazenamento de dados como um repositório. Assim, os aplicativos customizados podem monitorar e processar documentos no sistema ECM com a lógica de negócios necessária.

Voltar para parte superior

Usando Modo de Cliente em Processo

Para serviços de edição de dados temporários, para evitar a execução contínua do servidor de edição de dados (preservando, desse modo, os recursos) ou para reduzir o gasto adicional da comunicação entre processos, os documentos podem ser redigidos usando o modo cliente em processo. Esse modo dá um controle de aplicativo cliente pelo ciclo de vida do servidor de edição de dados. O servidor é inicializado junto com o cliente. Isso significa que o aplicativo customizado e o servidor de edição de dados estão executando no mesmo processo JVM, como mostrado na Figura 5.

Para usar a API do cliente de edição de dados no modo do cliente em processo, o método createInProcessClient() é usado para criar um objeto de classe RedactionToolkitClient em vez de usar o método createRemoteClient(). Diferente do cliente remoto, um cliente em processo não usa uma conexão SOAP. Ele inicia o servidor de edição de dados como um processo JVM. Assim que o objeto é obtido, o programa pode usar seus métodos do mesmo modo que ele faz no modo cliente remoto. A única diferença é que o método cleanup() deve ser chamado no fim do programa para liberar os recursos não necessários antes de parar o processo do JVM.

O programa do primeiro cenário é modificado para usar o cliente em processo simplesmente substituindo o método createRemoteClient() e incluindo o método cleanup().

A Listagem 10 mostra um exemplo de como usar o cliente em processo.

User user = new User("CustomApplication04", "userid", "password");
RedactionToolkitClient client = RedactionToolkitClient.createInProcessClient(user);
// redact the documents with the client object here
client.cleanup();

O cliente em processo é mais eficiente que o cliente remoto, visto que ele reduz o gasto adicional da comunicação entre processo. No entanto, o cliente remoto tem um acoplamento mais estreito entre o cliente e o processo do servidor. Aqui estão algumas preocupações adicionais com o cliente em processo.

Componentes do Servidor de Edição de Dados

O programa deve ser executado na mesma máquina que tem os componentes do servidor de edição de dados e deve estar executando na mesma JVM que os componentes do servidor (<IBM_REDACTION_HOME>\ibm-java2-jre-60\jre\bin\java.exe).

Os mesmos arquivos de configuração são usados para o servidor de edição de dados e o cliente em processo. No entanto, os serviços da Web (gerenciador de edição de dados e visualizador seguro), os serviços SOAP e o processador em lote não estão disponíveis no modo cliente em processo.

Coexistência com o Servidor de Edição de Dados

O cliente em processo pode ser usado mesmo quando o servidor de edição de dados está em execução, exceto quando o servidor de edição de dados está conectado aos servidores ECM. Quando o servidor de edição de dados está conectado aos repositórios (o armazenamento de dados) nos servidores ECM, ele bloqueia os repositórios. Assim, se o cliente em processo iniciar e também tentar se conectar aos servidores ECM, ocorrerá um conflito.

Classpath

Todos os arquivos jar listados na Tabela 4 devem ser incluídos no caminho de classe.

Em adição, se o armazenamento de objeto do Content Manager 8 é usado como um repositório, os arquivos jar e o diretório na Tabela 5 também são necessários no caminho de classe, onde <IBMCMROOT> é a pasta de instalação do IBM DB2 Information Integrator para Conteúdo. Esse produto é um pré-requisito apenas se o InfoSphere Guardium Data Redaction deve se conectar com o IBM Content Manager 8.

Requisitos da Opção de Início Java

O aplicativo customizado deve ser executado dentro dessas opções. Também pode ser necessário para modificar os tamanhos do conjunto de memórias.

-Xms256m -Xmx1536m -Djava.security.auth.login.config="%IBM_REDACTION_HOME%/server/conf/login.conf"

Voltar para parte superior

Conclusão

O uso básico da API cliente da edição de dados foi descrito com três cenários típicos de edição de dados e dois modos (cliente remoto e cliente em processo). Por usar o InfoSphere Guardium Data Redaction por meio dessa API em um aplicativo customizado, o fluxo de trabalho de documento no sistema pode ser melhorado e os processos de negócios podem ser feitos mais eficientes.

Voltar para parte superior

Agradecimentos

Os autores agradecem Joshua Fox e Michael Pelts, da equipe de desenvolvimento do InfoSphere Guardium Data Redaction. pela revisão e conselhos valiosos.

Recursos

Aprender

• Saiba mais sobre como compartilhar informações ao proteger a privacidade usando o IBM InfoSphere Guardium Data Redaction.
  
  
• Obtenha os recursos necessários na área de Information Management no developerWorks, para melhorar suas habilidades em uma grande variedade de produtos do IBM Information Management.
  
  
• Saiba mais sobre Information Management na zona de Information Management no developerWorks. Encontre documentação técnica, artigos de instruções, treinamento, downloads, informações de produtos, e muito mais.
  
  
• Siga o developerWorks no Twitter.
  
  
• Acompanhe Demos on demand do developerWorks que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidade avançada para desenvolvedores experientes.
  
  

Obter produtos e tecnologias

• Crie seu próximo projeto de desenvolvimento com software de avaliação da IBM, disponível para download diretamente no developerWorks, ou passe algumas horas no SOA Sandbox , aprendendo a implementar de forma eficiente a Arquitetura Orientada a Serviços.
  
  

Discutir

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

Sobre os autores

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• API do Cliente de Edição de Dados
• Cenário 1: Edição de Dados do Sistema de Arquivo Normal
• Cenário 2: Redigir Documentos em um Repositório em Lote
• Cenário 3: Redigir Documentos com um Repositório On Demand
• Usando Modo de Cliente em Processo
• Conclusão
• Agradecimentos
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais