Preguntas Frecuentes

IPF - Payments Framework from Icon. Es un marco con elementos de bajo código que permite a los clientes desarrollar su propia solución de procesamiento de pagos aprovechando el SDK central y cualquier módulo opcional deseado o paquetes de esquemas predefinidos.

IPF es agnóstico a la nube (es decir, no depende de una plataforma de nube específica), pero no es nativo de la nube.

Módulos Opcionales Adicionales (AOM) proporcionan funcionalidad de soporte que está sujeta a una licencia adicional además de la IPF Core licencia. Consulte aquí para más detalles.

Para la lista completa y más detalles, consulte aquí.

Sí, los modelos de datos internos utilizados en los componentes y aplicaciones de IPF se basan en ISO20022 tipos de mensaje. Consulte IPF ISO20022 Modelo.

Ninguno de los componentes, aplicaciones o soluciones de IPF construidos con IPF requiere ventanas de mantenimiento por defecto. Están diseñados de tal manera que soportan actualizaciones continuas con soporte de compatibilidad hacia atrás incorporado cuando es posible.

Las ventanas de mantenimiento son generalmente necesarias debido a los requisitos del entorno/infraestructura del cliente o a los sistemas del cliente que requieren dicho mantenimiento. Las soluciones de pago construidas con IPF deben ser capaces de soportar la indisponibilidad de esos sistemas dependientes gestionando el procesamiento de pagos en curso/nuevos de manera adecuada.

Sí, las soluciones de pago construidas con IPF y el soporte IPF applications admite soluciones para múltiples entidades legales. El procesamiento de pagos y las vistas de datos de pagos están lógicamente segregados por entidad de procesamiento, que es un identificador para una entidad legal.

Los tutoriales son un excelente lugar para comenzar.- Introducción al Tutorial

IPF utiliza una referencia única (unitOfWorkId) para todas las transacciones procesadas, y puede asegurar que customer las referencias proporcionadas están correlacionadas con una referencia interna de IPF para facilitar la reconciliación exitosa y proporcionar trazabilidad. Consulte Identificadores en IPF.

No, tanto las soluciones de pago instantáneo como las de pago no instantáneo pueden ser construidas utilizando IPF. El SDK también puede ser utilizado para construir prácticamente cualquier solución de procesamiento de pagos.

No, las soluciones construidas con IPF pueden procesar pagos iniciados de forma individual, en masa, inmediatos o con fecha futura. IPF también admite el procesamiento en días hábiles, así como ventanas de operación 24/7 y de compensación respaldadas por los respectivos CSM servicio.

Sí, IPF no solo proporciona un conjunto de validaciones de pago técnicas y comerciales, también es posible que los clientes codifiquen.custom validaciones comerciales que deben ser llamadas desde los flujos de procesamiento de IPF. Los pasos de proceso subyacentes en los flujos pueden integrarse con un sistema preexistente para realizar validaciones de pago.

IPF ha entregado un Operational Dashboard que proporciona la capacidad de buscar pagos/transacciones, ver el resumen/detalles de pagos, el historial de ejecución de pagos, el gráfico de ejecución en tiempo de ejecución, los mensajes en bruto intercambiados por un pago y más. No gestiona usuarios, pero admite el inicio de sesión único integrándose con el IAM del cliente a través de OAUTH o SAML. También admite mapping los roles de la interfaz gráfica a los roles específicos del cliente. Además de los datos de transacciones de pago, también hace API llamadas a varios IPF applications para recuperar y actualizar configuraciones y datos dinámicos.

IPF Operational Dashboard se basa en el marco de trabajo de la interfaz gráfica de usuario (GUI) de IPF, por lo tanto, es extensible. Los clientes pueden añadir sus módulos específicos (pantallas y API integraciones) utilizando las características del marco de trabajo IPF GUI y crear su propio customised/extend Operational Dashboard s. Ver IPF Operational Dashboard.

IPF proporciona un conjunto de API definiciones para devoluciones, retiradas y ROIs. Para API definiciones ver IPF APIs

La implementación de tal APIs está sujeta a los requisitos específicos del cliente y puede definirse fácilmente como flujos de procesamiento dentro de una orquestación IPF. Los flujos pueden definirse en MPS usando Payments DSL y la integración de sistemas específicos del cliente se puede lograr con el uso del conector IPF y mapping marcos.

Esta es la entidad para la cual se procesa un pago. Típicamente, es una sucursal de un cliente, por ejemplo, una entidad de procesamiento para el Reino Unido, una para la UE, etc. Consulte Entidades de Procesamiento.

La orquestación es una de las áreas clave donde IPF se distingue. Hemos construido nuestro propio Lenguaje Específico de Dominio (DSL) centrado en los pagos aprovechando JetBrains MPS que permite a los clientes construir soluciones utilizando el DSL con una dependencia mínima de Icon. Ver Marco de Orquestación y DSL 1 - Presentando el DSL de Icon. También se conoce como Flo-lang.

Sí, hemos construido nuestro propio Lenguaje Específico de Dominio (DSL) centrado en pagos aprovechando JetBrains MPS que permite a los clientes construir soluciones utilizando el DSL con una dependencia mínima de Icon. Ver Marco de Orquestación y DSL 1 - Presentando el DSL de Icon. También se conoce como Flo-lang.

Usando Payments DSL, un cliente podrá definir sus propios flujos de procesamiento de pagos según sus requisitos. Payments DSL ofrece capacidades de orquestación claras y permite el uso directo de un ISO20022 modelo de datos canónico basado en pagos.

Al definir sus flujos de orquestación, los clientes pueden agregar los modelos de datos requeridos de la biblioteca de datos canónicos de IPF. Los modelos de datos específicos del cliente, cuando sea necesario, pueden ser importados, lo que significa que los datos específicos del cliente pueden convertirse en parte del procesamiento, así como los modelos de datos canónicos genéricos de IPF.

El flujo se compone de estados y eventos, donde los eventos proporcionan el desencadenante para moverse entre estados.

El SDK y el DSL ofrecen una serie de características y funcionalidades:

Para más detalles sobre esto,Marco de Orquestación

Usando el MPS JetBrains Editor y el IPF Payments DSL. Pruébelo Introducción al Tutorial

A domain event es un hecho crítico, el evento significa que ha ocurrido algo específico que puede causar algún cambio en el procesamiento de nuestro pago. Los eventos de dominio le ayudan a expresar, explícitamente, las reglas del dominio y se basan en el lenguaje ubicuo proporcionado por los expertos en el dominio.

En las orquestaciones de IPF, domain events son partes críticas del procesamiento de pagos, declaradas explícitamente. Solo se publican si están registradas. Son inmutables. Se utilizan para cargar el estado actual de un agregado (transacción) al reproducir los registros.domain events sin efectos secundarios. También proporcionan el historial de ejecución - "¿Qué sucedió con la información de mi transacción?"

Los eventos del sistema IPF ocurren cuando algo ha sucedido en el sistema y tienden a ser bastante granulares. Pueden ser utilizados para notificar a los consumidores sobre diversos eventos que tienen lugar en el ecosistema IPF (o cualquier sistema relacionado con el procesamiento interno de los componentes y aplicaciones de IPF). Estos pueden ser convertidos en estadísticas significativas, reformateados y transmitidos a otros sistemas posteriores para su consumo y acción subsiguiente. También es posible definir eventos del sistema específicos para el cliente, especialmente utilizados dentro de las implementaciones del cliente. Consulte IPF System Events para más información.

Los eventos del sistema pueden ser registrados en un archivo de registro o publicados en un Kafka tema, y esto es configurable a través de la configuración de la aplicación. Consulte IPF System Events para más información.

Sí, los eventos del sistema específicos del cliente pueden ser definidos siguiendo el marco de eventos del sistema IPF y la estructura del evento. Los eventos del sistema del cliente se definirán dentro de las implementaciones IPF específicas del cliente. Para más información sobre cómo hacer esto, consulte Defina Events

IPF ofrece muchas características para apoyar el seguimiento, la monitorización y el archivo de pagos o datos de transacciones relacionadas.

Archivado: IPF puede proporcionar los datos de pago agregados y la información de procesamiento en el formato canónico de IPF publicado en un tema de kafka, de modo que los clientes puedan consumir y transformar/empujar la información a su sistema de archivado.

Eventos de dominio: Las soluciones de pago construidas con IPF pueden publicar domain events(hechos registrados sobre un pago durante el procesamiento, p. ej. SanctionsCheckPassed) en un sistema centralizado Kafka tema. Este enfoque permite al cliente reaccionar rápidamente ante cualquier pago crítico.domain event y, por ejemplo, enviar alertas a un operador del cliente.

Crudo Message Log ging: Cualquier mensaje intercambiado durante un proceso de pago puede ser publicado en un sistema centralizado. Kafka tema y también registrado en IPF ODS(Operational Data Store). Estos mensajes pueden ser consumidos y publicados en la solución de auditoría centralizada del cliente o pueden ser alimentados a ODS y accedido a través de ODS APIs. Estos también pueden ser mostrados a través de IPF Operational Dashboard pantallas como parte de la vista detallada de pagos.

Datos de Pago y Seguimiento: El IPF ODS a través de APIs(o IPF Operational Dashboard s) proporciona búsqueda de pagos, vista de resumen de pagos, vista detallada de pagos y para cada pago un historial de ejecución que se compone de domain events registrado para ese pago durante el procesamiento, gráfico de ejecución en tiempo de ejecución de un pago, mensajes en bruto intercambiados por un pago. Consulte IPF Operational Data Store - ODS para más información sobre ODS.

System Events: Los eventos del sistema IPF pueden ser utilizados para notificar a los consumidores sobre diversos eventos que ocurren en el ecosistema IPF (o en cualquier sistema relacionado con IPF). Estos pueden ser convertidos en estadísticas significativas o reformateados y transmitidos a otros sistemas posteriores para su consumo y acción subsiguiente. Consulte aquí el catálogo predeterminado del sistema.IPF System Events.

Las soluciones de pago construidas utilizando IPF también se benefician de la capacidad de crear eventos del sistema específicos para el cliente, además de la lista predeterminada. Los eventos del sistema, por defecto, pueden ser exportados a archivos de registro. Estos archivos de registro pueden ser agregados utilizando una aplicación de recopilación de datos (por ejemplo, Splunk, ELK, etc.) y utilizados para un monitoreo adicional.

Métricas: Los componentes principales de IPF proporcionan una lista predeterminada de métricas técnicas y comerciales útiles de IPF que ayudan a monitorear la solución. Para la lista predeterminada de métricas de conectores y aplicaciones, consulte:Métricas.

Estas métricas son además de las predeterminadas. JVM métricas y también métricas proporcionadas por el Akka marco que es la tecnología subyacente de IPF core. En segundo plano, IPF utiliza la telemetría de Lightbend que, a su vez, utiliza Open Telemetry. API para exportar métricas a varios backends. IPF por defecto expone estas métricas a través de Prometheus, lo que significa que las métricas se exportan utilizando Prometheus exportadores y mostrados en Grafana Tableros, consulte Métricas de Series Temporales.

Registro: IPF utiliza Logback para la configuración de registros. Esto permite al usuario configurar un sistema de registro que puede reflejar el de otras aplicaciones desarrolladas dentro de la organización. Consulte Registro.

Sí

Los mensajes intercambiados para un pago se almacenan como parte del registro de mensajes. Al definir un conector utilizando el marco de conector, el registro de mensajes puede implementarse de acuerdo con los requisitos de implementación de un cliente.

Los mensajes pueden ser publicados en un tema de procesamiento de datos centralizado. ODS ingestión, por ejemplo, consume de este tema y almacena los mensajes. Estos datos son consultables y ODS expone APIs para recuperar mensajes para un pago dado. Además, IPF Operational Dashboard tiene una pestaña en la vista de detalles de pago que lista todos los mensajes intercambiados para el pago seleccionado, logrado mediante una consulta ODS Inquiry API.

Sí - ver pregunta-¿Es posible ver qué mensajes en bruto se intercambiaron para un pago?

IPF admite una variedad de mecanismos y protocolos de integración gracias a su Marco de Conectores, que es un marco estandarizado para definir conectores (integraciones) con sistemas de clientes externos. Esto admite tanto integraciones síncronas como asíncronas, así como la mayoría de los protocolos de conectividad (MQ, Kafka,HTTP etc.) proporcionando integraciones altamente resilientes. El Marco de Conectores de IPF admite mecanismos de recuperación automática, como reintentos configurables, presión de retroceso, limitación y más. Consulte Marco de Conectores para más información.

Adicionalmente, IPF Operational Dashboard soporta la integración con el IAM del cliente a través de OAUTH/SAML para proporcionar la capacidad de inicio de sesión único. El marco de trabajo de la interfaz gráfica de usuario (GUI) de IPF, que ofrece la posibilidad de construir pantallas de interfaz de usuario específicas del cliente, proporciona integración OAUTH/SAML/LDAP con el IAM del cliente, de modo que cualquier interfaz de usuario construida utilizando el marco de trabajo de la GUI de IPF soporte fácilmente el inicio de sesión único.

Como parte del SDK, IPF ofrece customisable enfoque de orquestación e integración, respaldado por su conector (Marco de Conectores) y mapping(Mapping Framework desde IPF) marcos de trabajo. Lo que significa que un cliente no se integra con IPF, sino que utiliza IPF para definir y construir aplicaciones de procesamiento de pagos que se integran con el cliente y aplicaciones de terceros, ya sea de manera sincrónica o asincrónica. Esto se realiza utilizando formatos comunes de intercambio de datos (como XML or JSON) y una multitud de transportes (como HTTP, JMS, MQ, Kafka, etc).

Además, también hay un conjunto de aplicaciones de soporte listas para usar ofrecidas por IPF para soluciones de pagos. Estas aplicaciones proporcionan funciones comerciales reutilizables que pueden ser llamadas desde flujos de proceso, en forma de APIs. La integración con estas aplicaciones es generalmente una combinación de HTTP or Kafka/menajería APIs, en JSON formato.

También conocido como CSM Service, es un microservicio que aplica un mecanismo de compensación y liquidación dado (CSM) libro de reglas. Esto incluye la conectividad y el modelo de datos para formatear los mensajes que se enviarán y recibirán de un mecanismo de compensación y liquidación dado, por ejemplo, RT1, STET, STEP2. Consulte Scheme Pack s Introducción.

Un IPF application que es responsable de proporcionar información sobre la accesibilidad de los participantes. También ofrece diversas funciones comerciales útiles a través de su APIs como obtener CSMs accesibles, deconstruir IBAN, validar BIC, seleccionar CSM agente así como la gestión de configuraciones APIs. Ver CSM Reachability Service.

IPF viene con un Módulo Adicional Opcional (AOM) llamado Servicio de Resolución de Identidad, que aprovecha la tecnología de terceros de la empresa. NetOwl.

Como parte de este módulo, la solución es capaz de tomar el nombre y la dirección que están presentes en el mensaje de pago y compararlos con el nombre y la dirección que se encuentran en el customer sistema de información en el cliente. El servicio devolverá una puntuación (que se calcula en base a algoritmos de lenguaje complejos) que es interpretada por el flujo según umbrales configurables para determinar el siguiente paso. Por ejemplo, si la puntuación es inferior a 0.6, entonces eso podría significar que el pago es rechazado o enviado para intervención manual.Resolución de Identidad.

El servicio de notificación de estado de pago es una aplicación proporcionada como parte de IPF core y proporciona notificaciones de estado de pago del tipo Pain002 para los pagos que se están procesando en una solución de procesamiento de pagos IPF.

Los canales de los clientes suelen estar interesados en las notificaciones sobre el estado de los pagos, pero no desean ser inundados con cada pequeño cambio en el estado del pago. Las notificaciones Pain002 publicadas por el servicio de Notificación de Estado de Pago son cambios más significativos. La definición de lo que constituye un cambio de estado importante es configurable en función de un filtro.

El servicio de notificación de estado de pago es responsable de consumir domain events desde el procesamiento-de-datos-ipf Kafka tema y basado en un filtro configurable publicando notificaciones Pain002 en JSON formato a otro Kafka tema para que los sistemas del cliente consuman.Conceptos.

El IPF Operational Data Store (ODS) es la respuesta de IPF para habilitar vistas de datos a través de su procesamiento. Proporciona una visión unificada y, eventualmente, consistente del ciclo de vida de un pago de extremo a extremo. Este será el resultado de la ejecución de múltiples procesos, como la iniciación, ejecución, compensación y liquidación, y cancelación. También incluirá la integración con otros sistemas bancarios, como las verificaciones de fraude y sanciones.IPF Operational Data Store - ODS

An IPF application que proporciona una manera fácil y simple de gestionar tareas humanas que están registradas por flujos de procesamiento. Algunos ejemplos de tales tareas podrían ser aprobar o reparar un pago.

Human Task Managerproporciona APIs para buscar/listar, ver detalles de la tarea, reclamar/desreclamar, aprobar/rechazar y capturar el resultado de la ejecución de las tareas. Las pantallas de tareas detalladas y las pantallas de captura de resultados de tareas son específicas para el cliente. Consulte Comenzando con Human Task Manager(HTM).

Estas 2 validaciones se logran mediante el uso de un Caché de Transacciones, utilizado en la implementación para realizar la comparación de campos hasheados que deben ser especificados de acuerdo a customer requisitos. Consulte Verificación de duplicados Floclient.

Una configuración de procesamiento dinámica (DPS) es un término de IPF para la configuración dinámicamente modificable que se utiliza durante el procesamiento de un pago/transacción. Los cambios en los datos se aplican instantáneamente o se programan para ser aplicados, pero no requieren un reinicio de la aplicación para tener efecto.

Para que una configuración sea implementada como un DPS debe tener sentido desde la perspectiva del flujo de pago/transacción.

Para actualizar una configuración dinámica, puede ser necesario un proceso de aprobación, basado en una bandera de "requiere aprobación". Esto proporciona una mayor flexibilidad al actualizar una configuración, ya que no todas las actualizaciones pueden requerir aprobación.

Algunos ejemplos de las aplicaciones que están utilizando DPS are:

Las implementaciones de clientes también pueden crear custom configuraciones dinámicas utilizando DPS. Esto puede hacerse a través de una solución específica de implementación del cliente o utilizando custom configuración de procesamiento admitida en IPF core.

Ver Dynamic Processing Settings para más información.

ODS Ingestion: consume IPF Processing Data from Kafka, lo transforma en el ODS modelo de datos y persiste. Parte de esto ODS Los datos se publican a un actor de resumen de pagos, que enriquece los datos a su vez para crear/actualizar una vista de resumen persistente.

ODS Inquiry API: proporciona APIs para listar pagos, ver detalles de pagos, ver historial de ejecución domain events) para un pago, consulte una representación gráfica en tiempo de ejecución del flujo de procesamiento de una transacción y revise la lista de mensajes en bruto intercambiados para un pago.

También es posible almacenar y visualizar eventos del sistema dentro de ODS también. Para volúmenes más altos, se recomienda exportar eventos del sistema a archivos de registro y mostrarlos a través de una herramienta de agregación de registros como Splunk, en lugar de utilizar ODS.

Estos APIs son utilizados por IPF Operational Dashboard para presentar los datos en forma de paneles operativos y de auditoría, pero también puede ser utilizado para extraer la información a sistemas externos como Pega, etc.

Procesando aplicaciones que están construidas con el registro de orquestación IPF domain events como hechos importantes relacionados con un pago y se puede configurar para publicarlos en un sistema centralizado Kafka tema: procesamiento-de-datos-ipf.Los datos de este tema pueden ser consumidos por una aplicación construida por el cliente para alimentar prácticamente cualquier otro sistema del cliente según sea necesario.

ODSingestión proporcionada por IPF, consume el domain events de este tema y transforma el domain event datos en vistas consultables en la base de datos del lado de lectura. De la misma manera, otra aplicación puede consumir del mismo tema ipf-processing-data y proporcionar flujos descendentes según sea necesario.

Adicionalmente,ODS la consulta proporciona datos de pagos a través de ODS APIs desde las vistas consultables. Estos APIs puede ser utilizado y llamado para proporcionar los datos requeridos aguas abajo.

Es el valor del tamaño máximo del conjunto de búsqueda configurado para estar en ODS. El valor predeterminado es 1000.

IPF expone eventos del sistema y también Prometheus métricas (siguiendo el estándar de Open Telemetry). Estas pueden ser utilizadas para extraer métricas, realizar comparaciones y mostrar en paneles de control utilizando Grafana.

Los eventos del sistema pueden ser exportados a archivos de registro. Luego, es posible utilizar una herramienta de agregación de registros (por ejemplo, Splunk) y ver todos los eventos del sistema publicados por IPF applications

Los componentes principales de IPF proporcionan una lista predeterminada de métricas técnicas y comerciales específicas de IPF que ayudan a monitorear la solución. Para la lista predeterminada de métricas de conectores y aplicaciones, consulte:Métricas.

Estas métricas son además de las predeterminadas. JVM métricas y también métricas proporcionadas por el Akka el marco que es la tecnología subyacente de IPF core. En segundo plano, IPF utiliza la telemetría de Lightbend y admite la exportación de métricas a varios backends.

IPF por defecto expone estas métricas a través de Prometheus, lo que significa que las métricas se exportan utilizando Prometheus exportadores y mostrados en Grafana Tableros. IPF Operational Dashboard también admite la visualización Grafana tableros como widgets como parte de las pantallas de la interfaz de usuario.

En muchas aplicaciones, a menudo existen requisitos relacionados con el mantenimiento de un registro de cada mensaje. Esto podría ser para fines de monitoreo, auditoría o almacenamiento de datos. Independientemente del caso de uso, la biblioteca de conectores proporciona una instalación opcional de registro de mensajes que publicará tanto los mensajes enviados como los recibidos.

IPF utiliza Logback para la configuración de registros. Esto permite al usuario configurar un sistema de registro que puede reflejar el de otras aplicaciones desarrolladas dentro de la organización y hacer que IPF informe los datos de registro de la misma manera. Consulte Registro.

La orquestación de IPF y el marco de conectores proporcionan una variedad de mecanismos para hacer frente a fallos esperados y inesperados. Algunos ejemplos de estos mecanismos son:

La latencia para que un pago sea procesado dentro de una solución de pago construida con IPF depende principalmente de:

Los componentes principales de IPF están diseñados e ingenierizados para soportar aplicaciones de alto rendimiento y baja latencia con capacidades de resiliencia integradas.

En nuestras pruebas internas realizadas con una implementación hipotética de cliente (sample-client), utilizando simuladores para sistemas de cliente y el CSM, con la correcta escalabilidad y configuración podemos lograr una latencia de transacción de extremo a extremo inferior a 2s dentro del percentil 99.

IPF ha sido diseñado desde cero para ser escalable. IPF solutions puede ser implementado de manera activa-activa en múltiples centros de datos.

El Akka El marco de actores permite que los componentes funcionales se comuniquen de manera transparente con otros componentes, ya sea que los componentes se encuentren en el mismo host o en otros hosts dentro del mismo centro de datos o entre centros de datos.

Escalado Vertical El despliegue de las soluciones utilizando IPF requiere planificación de capacidad y dimensionamiento de los servidores anfitriones teniendo en cuenta:

Escalado Horizontal La escalabilidad horizontal de IPF dentro de ese contexto se logra mediante el despliegue de:

Para apoyar la máxima disponibilidad, se recomienda implementar IPF solutions on to n n 1 AZs/datacenters.

Las aplicaciones/soluciones construidas con IPF generalmente requieren lo siguiente como mínimo para su implementación:

El enfoque preferido para ejecutar aplicaciones es utilizando contenedores en Kubernetes. Sin embargo, también es posible ejecutar en VMs y Openshift localmente.

Icon proporcionará el software IPF (en forma de un SDK) que un socio de SI o cliente utilizará para implementar la solución requerida en el propio entorno del cliente y alojado por el cliente.

Las aplicaciones de procesamiento de pagos basadas en IPF son independientes de la nube y actualmente están comprobadas en AWS. También es posible implementar soluciones construidas con IPF en las instalaciones.

La contenedorización en IPF es por defecto en Kubernetes, implementando Docker los contenedores, sin embargo, Openshift también es compatible.

Las aplicaciones construidas con IPF están diseñadas para soportar actualizaciones continuas sin tiempo de inactividad.

Sin embargo, esto también está sujeto a implementaciones específicas del cliente y customisations introducido por el cliente.

También consulte Introducción al Tutorial

A partir de la versión V2024.1 (mayo de 2024), IPF utiliza Java 17/Spring 6/Spring Boot 3 para todos los componentes de IPF (todas las versiones de IPF anteriores a esta están utilizando Java 11). Necesitará usar Java 17 en diseño, construcción y tiempo de ejecución.

Java17 fue elegido basándose en intentar equilibrar el soporte de una versión LTS más reciente de Java y la capacidad de nuestros clientes para soportar/ejecutar esa versión.

IPF se basa en un conjunto de tecnologías bien conocido y ampliamente utilizado, lo que significa que la documentación para cada una de las tecnologías empleadas está en gran medida disponible en línea:

IPF proporciona documentación detallada y tutoriales para permitir un aprendizaje autodidacta efectivo que complementa la formación dirigida por instructores y la capacitación práctica.

Los documentos IPF son documentos vivos y se mantienen dentro del mismo repositorio que el código. Por lo tanto, para cualquier actualización de lanzamiento, la documentación respectiva se actualiza de manera consistente.

La documentación para desarrolladores de IPF está disponible en este sitio.-

IPF también proporciona generación de documentos de flujo para soluciones. La definición del flujo se realiza en MPS usando Payments DSL. Durante el proceso de construcción, IPF genera la documentación del flujo, la representación gráfica del flujo y los escenarios de prueba en forma de BDD. Toda esta salida puede ser utilizada como parte de los documentos de implementación específicos del cliente, eliminando la documentación manual para la orquestación.

Sí, la base de código de IPF se revisa periódicamente en nuestros escaneos de código internos como parte de nuestra pipeline de CI/CD para identificar cualquier vulnerabilidad:

IPF utiliza MongoDB base de datos que tiene sus propios mecanismos para asegurar los datos (Recurso:https://www.mongodb.com/docs/manual/security/[MongoDB Seguridad]), le recomendamos el uso de MongoDB mecanismos de cifrado ya que no se utiliza cifrado adicional en el lado de la IPF.

Para cifrar datos en reposo,MongoDB Enterprise ofrece cifrado de clave simétrica basado en almacenamiento nativo, lo que significa que los usuarios pueden utilizar cifrado de datos transparente (TDE) para cifrar archivos de base de datos completos a nivel de almacenamiento. Se ofreció por primera vez en la versión 3.2, MongoDB utiliza el Estándar de Cifrado Avanzado (AES) Algoritmo de cifrado de 256 bits, un cifrado que utiliza la misma clave secreta para cifrar y descifrar datos. El cifrado puede activarse utilizando el modo FIPS, asegurando así que el cifrado cumpla con el más alto estándar y normativas.

Toda la base de datos está cifrada utilizando Cifrado de Datos Transparente (TDE) a nivel de almacenamiento. Cada vez que se cifra un archivo de base de datos, se genera una clave de cifrado privada única. Todas las claves de base de datos generadas se cifran posteriormente con una clave maestra. La diferencia entre las claves de base de datos y la clave maestra es que las claves de base de datos pueden almacenarse junto con los datos cifrados; para la clave maestra MongoDB aconseja que se almacene en un servidor diferente, como soluciones de gestión de claves empresariales de terceros.

Para obtener más información sobre cómo configurar la encriptación de datos en reposo, por favor consulte la documentación oficial.https://docs.mongodb.com/manual/core/security-encryption-at-rest/[MongoDB documentación].

También apoyamos Cifrado a Nivel de Campo del Lado del Cliente (CSFLE).

Si bien la encriptación mejora la seguridad, la desventaja es que introduce algunos impactos en el rendimiento, los cuales se describen en el siguiente artículo (Recurso:https://www.mongodb.com/blog/post/at-rest-encryption-in-mongodb-3-2-features-and-performance[Cifrado de Datos en Reposo - Características y Rendimiento]).