Integre un proceso de redacción de datos de documento en su flujo de trabajo empresarial usando IBM InfoSphere Guardium Data Redaction

Consejos de programación de la API del cliente de redacción

IBM® InfoSphere® Guardium® Data Redaction proporciona una API de Java® que le permite a su aplicación personalizada usar el servidor de redacción. Este artículo describe cómo usar la API en tres escenarios típicos de redacción de documentos.

Yasutomo Nakayama, Yamato Software Development Laboratory (YSL), IBM

Yasutomo Nakayama es un miembro del equipo de desarrollo de Gestión de Contenido Empresarial en Yamato Software Development Laboratory (YSL), IBM Japan.



Eisuke Kanzaki, Yamato Software Development Laboratory (YSL), IBM

Eisuke Kanzaki es un miembro del equipo de desarrollo de Gestión de Contenido Empresarial en Yamato Software Development Laboratory (YSL), IBM Japan.



19-03-2012

Introducción

IBM InfoSphere Guardium Data Redaction soporta la divulgación selectiva de información en documentos. El servidor de redacción automáticamente elimina la información privada en documentos y formularios de texto libre, como se muestra en la Figura 1.

Estas funciones ayudan a procesar grandes números de documentos que pueden estar dispersos entre diversas ubicaciones. Cuando existan requisitos normativos o empresariales para mantener la privacidad de cierta información en los documentos, aunque específicamente revelando información relevante a personas autorizadas, el sistema de redacción puede ayudar a satisfacer ambas metas.

Este producto incluye aplicaciones basadas en navegador con interfaces intuitivas que le permiten redactar documentos o ver los documentos redactados. También ofrece múltiples opciones para acceso automatizado. Estos dispositivos pueden ser especialmente valiosos en flujos de trabajo de la Gestión de Contenido Empresarial (ECM), donde la redacción controlada es una parte esencial de la gestión de documentos.

Figura 1. Visión General de IBM InfoSphere Guardium Data Redaction
Visión General de IBM InfoSphere Guardium Data Redaction

Existen tres métodos para usar estos servicios de redacción:

  • Mediante repositorios de documentos o un sistema de archivos. Usted copia los documentos originales en una carpeta de entrada y recibe los archivos redactados en una carpeta de salida.
  • Mediante la API de SOAP, recomendada para aplicaciones que no sean de Java.
  • Mediante la API del cliente de redacción de JAVA, el enfoque de este artículo.

IBM InfoSphere Guardium Data Redaction proporciona una API de cliente de redacción de forma que sus aplicaciones personalizadas puedan controlar directamente el servicio de redacción mediante la API. Este artículo describe las posibilidades de la API del cliente de redacción y cómo usar la API en una aplicación personalizada. Hay tres escenarios descritos como ejemplos en este artículo.

Nota: este artículo está basado en IBM InfoSphere Guardium Data Redaction V2.1.


API del cliente de redacción

La API del cliente de redacción es una biblioteca de clase Java para acceder a los servicios del servidor de redacción desde un programa. El kit de herramientas de la API es incluido con InfoSphere Guardium Data Redaction.

Se proporcionan código de muestra de fábrica y documentación para las APIs. Cuando el producto es instalado, las bibliotecas de la API y un programa de muestra son copiados en la carpeta <IBM_REDACTION_HOME>\client, donde <IBM_REDACTION_HOME> es la carpeta de instalación. El documento de Java para la API también es copiado en la carpeta<IBM_REDACTION_HOME>\docs\apidocs.

Existen dos modos para usar el servicio de redacción de una aplicación personalizada con la API: un modo de cliente remoto y un modo de cliente en proceso. En el modo de cliente remoto, un programa en una máquina de cliente remota (o local) invoca el servidor de redacción mediante una conexión de SOAP. En el modo de cliente en proceso, todo el servidor de redacción se ejecuta como parte de la aplicación del cliente. La implementación del programa es casi la misma en ambos modos. En estos ejemplos, el uso de la API en el modo de cliente remoto es mostrado primero para cada uno de los tres escenarios típicos. Finalmente, las diferencias entre los dos modos son descritas.

El primer escenario es el más básico. Un programa de cliente simplemente se conecta al servidor y redacta un documento. En el segundo escenario, muchos documentos son enviados al servidor y son redactados usando un repositorio de lote. El tercer escenario es un caso avanzado mostrando el alto nivel de control que una aplicación tiene sobre la redacción de una colección de documentos.


Escenario 1: redacción del sistema de archivos local

Este es el escenario más simple e ilustra el uso básico de la API. En este escenario, un programa en una máquina de cliente remota envía una solicitud de redacción al servidor de redacción, como se muestra en la Figura 2.

Figura 2. Solicitud de redacción enviada al servidor de redacción
Solicitud de redacción enviada al servidor de redacción

El escenario involucra estas etapas:

  1. Establecer una conexión con el servidor de redacción
  2. Cargar un documento de destino como datos binarios
  3. Enviar una solicitud de redacción
  4. Salvar el resultado como un documento

Establecer una conexión con el servidor de redacción

Para conectarse al servidor de redacción, primero cree un objeto de clase RedactionToolkitClient . El método createRemoteClient() es usado para crear el objeto en el modo de cliente remoto. El Listado 1 muestra un ejemplo de cómo usar el método createRemoteClient() .

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

Cuando el método createRemoteClient() es invocado, una conexión de SOAP entre la máquina del cliente remota y el servidor de redacción es establecida. Por lo tanto, el método requiere la dirección IP y el número de puerto del servidor de redacción. También requiere un ID de usuario válido y una contraseña para el servidor de redacción. Una vez que el servidor de redacción y el cliente están conectados, su aplicación puede invocar los servicios del servidor mediante el motor de SOAP. La API proporciona varios métodos para invocar los servicios de redacción.

Cargar un documento de destino como datos binarios

El servidor de redacción soporta varios formatos de documento tales como PDF, Microsoft Word, imágenes tiff y texto plano. Para todos los formatos, el contenido del documento debe ser pasado al servidor como una matriz binaria. Por lo tanto, los archivos deben abrirse en modo binario al redactar documentos en un sistema de archivos.

Enviar una solicitud de redacción

El método redactDocumentByRules() envía una solicitud de redacción al servidor. Este método requiere varios parámetros para especificar las opciones para la solicitud. La Tabla 1 a continuación lista las clases que son usadas para especificar los parámetros para la solicitud.

Tabla 1. Clases usadas para el método redactDocumentByRules()
ClaseParámetros a establecer
RedactionAttributes formato de salida, norma de enmascarado, modo de color, estampa y otras opciones de redacción
RedactionStamp etiqueta de estampa y posición
DocumentAttributes nombre del documento, idioma del documento, etc.
Document datos del documento (binario), DocumentAttributes objeto de clase

El objeto de clase RedactionAttributes especifica cómo redactar el documento. El Listado 2 muestra cómo establecer los atributos de redacción para este objeto de clase. En esta muestra, “image/png” es especificado como el tipo de contenido de salida, GRAY como el modo de color de salida y "Classified" como la estampa en la esquina superior izquierda de las páginas del documento. El objeto RedactionAttributes.ColorMode.GRAY es una constante estática para especificar el modo de color.

Listado 2. Establecer los atributos de redacción
// 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);

El objeto de clase Document es usado para establecer la información sobre el documento de entrada y para obtener la información en el documento redactado. La clase DocumentAttributes es usada para mantener los metadatos de la clase Document tales como el nombre del documento, el tipo de contenido, el idioma y otros.

En el Listado 3, el nombre y el tipo de contenido del documento de entrada es especificado por el constructor. Cuando "" es especificado como el tipo de contenido, el servidor de redacción examine los datos del documento e identifica el tipo. El idioma del documento (inglés) es establecido para el objeto al usar el método addAttribute() . Si el idioma no es especificado, el sistema lo identifica automáticamente durante el proceso de redacción. Los datos binarios para el documento, la instancia de documentAttributes y el estado del documento son establecidos en el objeto de clase Document . En este código de muestra, los datos binarios del documento son almacenados en la variable inputDocBytes .

Listado 3. Use Document class object
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);

IBM InfoSphere Guardium Data Redaction tiene 13 categorías semánticas principales predefinidas, como se muestra en la Tabla 2, de forma que puede especificar qué palabras deben ser redactadas en los documentos. Se pueden crear categorías adicionales conforme sea necesario.

Tabla 2. Categorías de semántica predefinidas
ID de CategoríaCategoría de Semántica
2 Número Telefónico
3 Organización
4 Fecha
5 Hora
6 SSN (Número de Seguro Social)
7 Dirección de e-mail
8 URL
9 Ubicación
10 Persona
11 Dirección
100 USD (dólares americanos)
101 Nacionalidad
102 Número de Tarjeta Bancaria

Cuando una solicitud de redacción es enviada al servidor usando el método redactDocumentByRules() , los tipos de datos de destino para redacción son especificados. El Listado 4 muestra un ejemplo de cómo preparar las normas de redacción y llamar al método. Este ejemplo especifica que el número telefónico, el nombre del personal y la dirección deben redactarse.

Listado 4. Prepare redaction rules
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);

Los tipos de datos para redacción pueden ser especificados más fácilmente usando roles. Los permisos para las diversas categorías de semántica (como si hay que redactar o no) son especificados para cada rol. Juntos, las normas y los roles son llamados un modelo de política, que debe ser definido en un archivo XmlPolicyModel.xml en la carpeta <IBM_REDACTION_HOME>\server\conf en el servidor de redacción.

El método redactDocumentForRole() es usado para especificar el rol como una opción de redacción. El Listado 5 muestra un ejemplo de cómo usar el método redactDocumentForRole() . El rol RESTRICTED (ID 1000) es uno de los roles de muestra del producto. Normalmente, usted debe definir sus propios roles que se ajusten a su lógica empresarial con las categorías de semántica predefinidas.

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

Salvar el resultado como un documento

El método redactDocumentByRules() y el método redactDocumentForRole() retornan un objeto de clase Document como el resultado redactado. Los datos binarios y el nombre del documento de este objeto son usados para salvar el documento en un archivo local.

Este escenario es mejor para los clientes que requieren procesamiento sincrónico. La conexión con el servidor de redacción se mantiene viva hasta el final de la redacción. Esto permite a los clientes realizar el seguimiento del proceso y controlar la ejecución de las redacciones. Los parámetros de redacción son pasados con cada documento individual. Para un mejor rendimiento, los clientes pueden enviar solicitudes de redacción desde múltiples hebras. El segundo escenario es adecuado para la redacción de grandes cantidades de documentos cuando la aplicación del cliente no debe estar bloqueada.


Escenario 2: Redactar documentos en un repositorio de lote

Un repositorio es una carpeta especificada, incluyendo subcarpetas, en un sistema de archivos o en un sistema de ECM. Es usado para documentos de entrada y de salida así como para otros artefactos usados en la redacción. Existen dos tipos de repositorios: de lote y on-demand. Un repositorio de lote es usado en este segundo escenario. El servidor de redacción es establecido para supervisar la carpeta de entrada del repositorio de lote para documentos entrantes. Cuando los documentos son copiados en la carpeta de entrada, el servidor automáticamente comienza a redactar los documentos con las opciones que son definidas por adelantado para el repositorio, y pone los resultados en la carpeta de salida.

En este escenario, la aplicación personalizada es dividida en dos partes, como se muestra en la Figura 3. La primera parte, la aplicación personalizada A, simplemente envía los documentos al repositorio de lote. Después de que el servidor ha procesado los documentos, la segunda parte, la aplicación personalizada B, se conecta al servidor y descarga los documentos redactados.

Figura 3. Aplicación personalizada dividida en dos partes
Aplicación personalizada dividida en dos partes

La Tabla 3 muestra los métodos relacionados con el repositorio de la clase RedactionToolkitClient . Este escenario es implementado al usar algunos de estos métodos.

Tabla 3. Métodos para operar en repositorios
MétodoOperación
queryDocumentRepository() Obtener una lista de los documentos en el repositorio
addDocumentToRepository() Añadir un documento al repositorio
getRepositoryDocument() Obtener un documento del repositorio
deleteRepositoryDocument() Suprimir un documento en el repositorio
redactRepositoryDocumentByRules() Redactar un documento en el repositorio de acuerdo a la norma especificada
redactRepositoryDocumentForRole() Redactar un documento en el repositorio de acuerdo al permiso para el rol de recipiente especificado

Enviar los documentos

La aplicación personalizada A se conecta al servidor y carga los documentos de destino. Estas operaciones son similares a las primeras dos etapas en el Escenario 1.

El método addDocumentToRepository() pone un documento en la carpeta de entrada del repositorio especificado. El Listado 6 muestra un ejemplo de cómo usar el método addDocumentToRepository() . El "lote" es el nombre de uno de los repositorios de lote de muestra que es creado cuando el producto es instalado.

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

La aplicación continúa subiendo hasta que todos los documentos han sido enviados al repositorio. Cuando el último documento ha sido subido, el programa se finaliza.

El servidor está supervisando la carpeta de entrada y automáticamente comienza a procesar los documentos. Esto hace que sea innecesario mantener una conexión con el servidor durante el procesamiento. Los documentos son procesados con las opciones que son definidas en el archivo de configuración que está almacenado en el servidor de redacción para ese repositorio.

Descargar los documentos y limpiar el repositorio

Después, la aplicación B se conecta al servidor de redacción y verifica la carpeta de salida del repositorio. El método queryDocumentRepository() obtiene las referencias para los documentos en el repositorio especificado. El Listado 7 muestra un ejemplo de cómo utilizar el método queryDocumentRepository() .

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

Para encontrar los documentos redactados, DocumentRepositorySearchCriteria.SEARCH_WITHIN.REDACTED debe ser especificado como el tipo de documentos a buscar, lo que se refiere a los documentos que han sido redactados en lugar de los documentos originales. Los resultados de la consulta son retornados en la matriz de la clase DocumentReference . Las referencias son usadas para especificar los documentos en las carpetas del repositorio a ser descargados o suprimidos. El método getRepositoryDocument() obtiene los datos del documento reales, la clase de objeto Document . Aún después de que los datos son descargados, los datos originales se mantienen en el repositorio. El método deleteRepositoryDocument() es llamado para limpiar el repositorio. El Listado 8 muestra un ejemplo de cómo usar los métodos getRepositoryDocument() y deleteRepositoryDocument() .

Listado 8. Use the getRepositoryDocument() and deleteRepositoryDocument() methods
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]);
}

Un repositorio de lote está diseñado para redactar muchos documentos a la vez por un número de hebras configurables. Un conjunto de opciones de redacción, por ejemplo el formato de salida, el modo de color, el rol y otros, puede ser especificado para cada repositorio. Si hay distintas opciones de redacción para distintos documentos, entonces un repositorio de lote debe ser preparado para cada conjunto de opciones. En contraste, con un repositorio on-demand, puede controlar cómo el servidor redacta cada documento en el repositorio.


Escenario 3: Redactar documentos con un repositorio on-demand

En el tercer escenario, la aplicación personalizada es dividida en tres partes. Subir y descargar partes es casi lo mismo que en segundo escenario, excepto que los documentos se ponen en un repositorio on-demand. A diferencia del repositorio de lote, el repositorio on-demand no comienza a redactar el documento de entrada automáticamente. Por lo tanto una nueva parte, la aplicación personalizada C, debe estar en ejecución en la máquina del servidor para solicitar que el servidor procese los documentos, como se muestra en la Figura 4.

Figura 4. La aplicación personalizada C se ejecuta en la máquina del servidor para solicitar el proceso de redacción
La aplicación personalizada C se ejecuta en la máquina del servidor para solicitar el proceso de redacción

La aplicación personalizada A sube los documentos al repositorio on-demand. Esto puede hacerse repetidamente como sea necesario. La aplicación personalizada C en la máquina del servidor se ejecuta con una planificación regular, como una vez al día, cuando verifica el repositorio para encontrar los documentos.

La aplicación C se está ejecutando en la máquina del servidor, sin embargo aún se conecta al proceso del servidor mediante una conexión de SOAP, ya que createRemoteClient() es usado como en las otras aplicaciones personalizadas. Las referencias para los documentos en la carpeta de entrada del repositorio son obtenidas al usar el método queryDocumentRepository() con la opción DocumentRepositorySearchCriteria.SEARCH_WITHIN.NOT_REDACTED . Los métodos redactRepositoryDocumentByRules() o redactRepositoryDocumentForRole() son usados para redactar los documentos en las carpetas de repositorio on-demand.

La aplicación puede especificar distintas opciones para cada documento al usar la clase RedactionAttributes y los roles o normas requeridos por la lógica empresarial. Por ejemplo, distintos roles pueden ser especificados para cada documento al referirse a cada nombre del documento.

El Listado 9 muestra un ejemplo para usar el método redactRepositoryDocumentForRole(). En este código, los documentos cuyo prefijo de nombre de archivo es “ClassA” están redactados con el rol RESTRICED y la estampa “Classified” es añadida a las páginas.

Listado 9. Use redactRepositoryDocumentForRole() method
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 escenario puede ser extendido para integrar el proceso de redacción del documento en el flujo de trabajo del documento conforme sea requerido. El servidor de redacción puede acceder a un sistema de ECM y usar su almacén de datos como un repositorio. Por lo tanto, las aplicaciones personalizadas pueden supervisar y procesar documentos en el sistema de ECM con la lógica empresarial requerida.


Usando el modo de cliente en proceso

Para los servicios de redacción en el punto, para evitar ejecutar el servidor de redacción continuamente (conservando así los recursos) o para reducir la sobrecarga de comunicación entre procesos, los documentos pueden ser redactados al usar el modo de cliente en proceso. Este modo le da al cliente control de la aplicación durante el ciclo de vida del servidor de redacción. El servidor es inicializado junto con el cliente. Esto significa que la aplicación personalizada y el servidor de redacción se están ejecutando en el mismo proceso de JVM, como se muestra en la Figura 5.

Figura 5. Redactando un documento en el modo de cliente en proceso
Redactando un documento en el modo de cliente en proceso

Para usar la API del cliente de redacción en el modo de cliente en proceso, el método createInProcessClient() es usado para crear un objeto de clase RedactionToolkitClient en lugar de usar el método createRemoteClient() . A diferencia del cliente remoto, un cliente en proceso no usa una conexión de SOAP. Inicia el servidor de redacción como un proceso de JVM. Una vez que el objeto es obtenido, su programa puede usar sus métodos en la misma forma que lo hace en el modo de cliente remoto. La única diferencia es que el método cleanup() debe ser llamado al final del programa para liberar los recursos innecesarios antes de detener el proceso de la JVM.

El programa para el primer escenario es modificado para usar el cliente en proceso al simplemente sustituir el método createRemoteClient() y añadir el método cleanup() .

El Listado 10 muestra un ejemplo de ´como usar el cliente en proceso.

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

El cliente en proceso es más eficiente que el cliente remoto, ya que reduce la sobrecarga de comunicación entre procesos. Sin embargo, el cliente remoto tiene un acoplamiento más estrecho entre los procesos del cliente y el servidor. Estas son algunas preocupaciones adicionales con el cliente en proceso.

Componentes del servidor de redacción

El programa debe ser ejecutado en la misma máquina que tiene los componentes del servidor de redacción, y debe ejecutarse en la misma JVM que los componentes del servidor (<IBM_REDACTION_HOME>\ibm-java2-jre-60\jre\bin\java.exe).

Los mismos archivos de configuración son usados para el servidor de redacción y el cliente en proceso. Sin embargo, los servicios Web (gestor de redacción y visor seguro), los servicios de SOAP y el procesador de lote no están disponibles en el modo de cliente en proceso.

Coexistencia con el servidor de redacción

El cliente en proceso puede ser usado aún cuando el servidor de redacción se está ejecutando, excepto cuando el servidor de redacción está conectado a servidores de ECM. Cuando el servidor de redacción está conectado a los repositorios (el depósito de datos) en los servidores de ECM, bloquea los repositorios. Por lo tanto, si el cliente en proceso se inicia y también intenta conectarse a los servidores de ECM, ocurre un conflicto.

Classpath

Todos los archivos jar listados en la Tabla 4 deben ser añadidos a la ruta de acceso de clases.

Tabla 4. Los archivos jar requeridos en la ruta de acceso de clases para el cliente en proceso
Todos los archivos jar en <IBM_REDACTION_HOME>\server\lib
Todos los archivos jar debajo de <IBM_REDACTION_HOME>\server\plugins

Además, si el depósito de datos Content Manager 8 es usado como repositorio, los archivos jar y el directorio en la Tabla 5 también son requeridos en la ruta de acceso de clases, donde e <IBMCMROOT> es la carpeta de instalación de IBM DB2 Information Integrator for Content. Este producto es un requisito previo sólo si InfoSphere Guardium Data Redaction se conectará con IBM Content Manager 8.

Tabla 5. Los archivos jar y el directorio requerido para la conexión de CM8
<IBMCMROOT>\lib\cmbcm81.jar
<IBMCMROOT>\lib\cmbicm81.jar
<IBMCMROOT>\lib\db2jcc_license_cisuz.jar
<IBMCMROOT>\lib\db2jcc_license_cu.jar
<IBMCMROOT>\lib\db2jcc.jar
<IBMCMROOT>\cmgmt

Requisitos de opción de inicio de Java

La aplicación personalizada debe ejecutarse con tres opciones. También puede ser necesario modificar los tamaños de agrupación de memoria.

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


Conclusión

El uso básico de la API del cliente de redacción ha sido descrito con tres escenarios típicos de redacción y dos modos (cliente remoto y cliente en proceso). Al usar InfoSphere Guardium Data Redaction a través de esta API en una aplicación personalizada, el flujo de trabajo del documento en el sistema puede ser mejorado y los procesos empresariales pueden hacerse más eficientes.


Agradecimientos

Los autores desean agradecer a Joshua Fox y Michael Pelts del equipo de desarrollo de InfoSphere Guardium Data Redaction por su revisión y sus valiosos consejos.

Recursos

Aprender

Obtener los productos y tecnologías

  • Construya su próximo proyecto de desarrollo con software de prueba IBM, disponible para descarga directamente desde developerWorks, o invierta algunas horas en el SOA Sandbox aprendiendo cómo implementar eficientemente la Arquitectura Orientada al Servicio.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt
ArticleID=806155
ArticleTitle=Integre un proceso de redacción de datos de documento en su flujo de trabajo empresarial usando IBM InfoSphere Guardium Data Redaction
publish-date=03192012