Identificadores en IPF
Hay muchos identificadores dentro de IPF application componentes, y a menudo puede ser confuso y abrumador entender cuál identificadores que usted es responsable de proporcionar como un IPF application desarrollador frente a los que son internos, y los impactos y la relación cada identificador tiene con otros identificadores y el comportamiento de la aplicación.
Esta página tiene como objetivo catalogue todos los identificadores principales que puede encontrar al utilizar IPF. Los detalles de cada identificador están documentados por categoría de dominio y también se pueden acceder a través de la barra lateral de contenidos estáticos.
| Componente | Identificador |
|---|---|
Contexto de Procesamiento |
|
Contexto de Procesamiento |
|
Contexto de Procesamiento |
|
Contexto de Procesamiento |
|
Contexto de Procesamiento |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Process Flow |
|
Servicio de Correlación |
|
Message Log |
|
IPF API Solicitud |
|
Estructura de Datos del Mensaje |
|
Operational Data Store |
|
Operational Data Store |
|
Mensajes ISO20022 |
|
Mensajes ISO20022 |
|
Mensajes ISO20022 |
|
Mensajes ISO20022 |
Contexto de Procesamiento
Unit of Work ID
unit Of Work Id
El Unit of Work ID es un identificador interno de IPF que rastrea el procesamiento global de un elemento de trabajo (típicamente un pago) a lo largo de todo el recorrido dentro de los servicios de procesamiento de IPF.
El valor es interno y no debe derivarse de ningún contenido del mensaje.
¿Quién especifica este valor?
El IPF core código de aplicación.
El primer punto de entrada de la aplicación controlada por Icon, típicamente un Iniciador Receive Connector activará la generación de un nuevo Unit of Work ID dentro de un nuevo Contexto de Procesamiento.
Comentarios del desarrollador
Actualmente, los pagos entrantes (en varias soluciones) son mapping este valor de los Identificadores de mensaje dentro de los mensajes financieros (por ejemplo, grpHdr.msgId). Estos valores de msgId son únicos solo dentro de una escala temporal dada dentro de un esquema; además, msgId a menudo se utiliza en la verificación de duplicados funcionales/técnicos, lo cual NO se proporciona en relación con unitOfWorkId. |
ID de Solicitud del Cliente
client Request Id
El ID de Solicitud del Cliente es un campo único que está reservado para la asignación a un valor específico del cliente que permitirá la asociación y consulta a un IPF.unit of work.
Permite a los clientes consultar los estados y detalles de los pagos a partir de "su" identificador.- en lugar de necesitar mantener una referencia a un Unit of Work ID.
¿Quién especifica este valor?
La solución cliente IPF.
El primer punto de entrada de la aplicación controlada por Icon, típicamente un Iniciador Receive Connector, delega a una solución específica mapper que opcionalmente extrae un clientRequestId desde un mensaje inicial.
A menudo el ID de Solicitud Externa se utiliza el mensaje de inicio.
Entidad de Procesamiento
processing Entity
Un identificador interno que el IPF Solution ha definido referirse a la entidad física que está asociada con el procesamiento del trabajo para un IPF Solution.
Ubicaciones comunes
-
Contexto de Procesamiento
-
Cada objeto emitido desde IPF-Data-Egress
-
Configuración de Procesamiento
¿Quién especifica este valor?
Esto puede configurarse como parte de la configuración de procesamiento o de la configuración estándar de la aplicación.
Cualquier componente de IPF puede optar por actualizar el Entidad de Procesamiento dentro del Contexto de Procesamiento en un momento dado.
ID de Asociación
association Id
El ID de Asociación dentro del Contexto de Procesamiento asocia un punto en el tiempo event(such as a message-log or system event emisión, etc.) con un contexto local como un Flujo de Procesamiento IPF. De esta manera, podemos state "esto" message log fue causado por este Flujo" en lugar de ser creado para una única unit Of Work que puede abarcar múltiples servicios y flujos.
El ID de Asociación el campo en sí no hace ninguna suposición sobre el significado o la referencia de su valor. Es un campo en bruto que solo debe utilizarse dentro de un contexto conocido. Dicho esto, el 90% del caso de uso actual es para que esto se refiera al ID de persistencia del Process Flow que se está ejecutando actualmente.
¿Quién especifica este valor?
El IPF application es responsable de establecer este valor y de utilizar este valor de manera apropiada según el contexto.
Comentarios del desarrollador
El <<associationId>> comenzó como un campo de datos puramente para poder asociar puntos de datos con otra etiqueta. Se está utilizando en muchos casos de uso para ayudar a gobernar el flujo de control al almacenar <<persistenceId>> del _IPF que se está ejecutando actualmente Process Flow_. Idealmente, esta "convención" debería ser formalizada, ya sea mediante la imposición de tipos o dividiendo las preocupaciones en campos separados. Se siente inseguro que este valor en bruto se utilice de manera diferente en distintos contextos en el futuro. |
Punto de control
checkpoint
A Punto de control se refiere a un identificador para el último "procesamiento event " que ocurrió para un Contexto de Procesamiento dado."
A "procesamiento event "puede ser uno de (pero no se limita a):"
-
Domain Event siendo persistido
-
Message log siendo emitido
-
System Event siendo emitido
El valor del checkpoint es un identificador dependiente del tipo de "procesamiento".event ". El tipo en sí, por convención, se incluye como parte del identificador como un prefijo."
Un punto de control se refiere a un processingObjectId.
¿Quién especifica este valor?
El IPF application los componentes principales deben actualizar automáticamente esta propiedad:
-
Flo-Lang actualiza el punto de control en función de la efectividad processObjectId for the last Domain Event persistió. El marco Connector se actualizará automáticamente.Punto de control basado en el efectivo Process Object ID para el último Mensaje Enviado/Recibido (a través de Message Log).
Ejemplo
A Punto de control para un Domain Event:
PROCESS_FLOW_EVENT|PaymentInitiation|abc-123-ef-456|3
A Punto de control pertinente a Message Log:
MESSAGE_LOG|jgjfgdg884t722
Process Flow s
ID de persistencia
persistence Id
El ID de persistencia es una referencia única, dentro de una única definición de servicio Akka, a una instancia de un actor de persistencia. En el caso de IPF, esto suele ser una instancia de un Process Flow. La implementación predeterminada consta de dos partes, un Tipo de entidad y ID de entidad.
Para obtener más información, consulte la documentación oficial de Lightbend sobre Persistence IDs en Akka.
¿Quién especifica este valor?
El IPF application es responsable de proporcionar este valor al enviar comandos a un IPF Processing Flow. El valor en sí se almacena típicamente en el Processing Context como un ID de Asociación.
Tipo de entidad
entity Type
El Tipo de entidad es el nombre de un comportamiento definido por un Akka actor persistente. En IPF este es el nombre del Flujo de Procesamiento. Este es el nombre del flujo descrito en MPS y muchos de los generados resultantes Java las clases tienen el Tipo de entidad como un prefijo (por ejemplo, Payment Initiation Process Flow, Payment Initiation Initialiser etc).
En el contexto de IPF Processing Flows se compone de flowName + flowVersion si el flujo está versionado.
Para obtener más información, consulte la documentación oficial de Lightbend sobre Persistence IDs en Akka.
¿Quién especifica este valor?
Este valor se establece durante la definición del Flujo de Procesamiento IPF en el momento de la construcción.
Unicidad
Requiere unicidad dentro de un IPF Service.
Causará problemas de agregación de datos si no es globalmente único en un IPF Solution.
Ejemplo
Dentro de los ejemplos a continuación de un ID de persistencia, la sección resaltada captura el Tipo de entidad sección.
Un-versioned:
PaymentInitiation|abc-123-ef-456
Versionado:
PaymentExecutionv1|abc-123-ef-456
Comentarios del desarrollador
|
Tipo de entidad se asume que es único en un IPF Solution. Existe una capacidad para la superposición de datos si diferentes IPF Services dentro de un solo IPF Solution tener lo mismo Tipo de entidad. Por ejemplo, el ODS almacena metadatos para la "definición" de cada IPF Processing Flow, que está indexado por ID de Definición de Flujo, basado en Tipo de entidad. |
ID de entidad
entity Id
El ID de entidad representa un identificador interno que identifica de manera única una entidad de dominio, que puede ser representada en uno o más Akka_Actores Persistentes_. En el contexto de IPF, esto significa múltiples Flujos de Procesamiento IPF.
Para obtener más información, consulte la documentación oficial de Lightbend sobre Persistence IDs en Akka.
Ejemplo
En el siguiente ID de persistencia ejemplo, la sección resaltada captura el ID de entidad.
PaymentInitiation|abc-123-ef-456
Comentarios del desarrollador
Este valor ha asumido unicidad por el marco _Akka_, por lo que puede ser tentador utilizarlo como base para proporcionar verificación de duplicados funcional. Sin embargo, debe ser realmente siempre un UUID (v4) generado aleatoriamente de forma interna. La verificación de duplicados debe implementarse a través de funciones comerciales estándar. |
Event ID
event Id
El Event ID es un identificador único de un IPF Process Flow Domain Event dentro de un despliegue. El Event ID es un identificador compuesto basado en el ID de persistencia y la secuencia para eso event dentro del contexto de un sello de tiempo de Lamport en el unit Of Work.
ID de Definición de Flujo
flow Definition Id
Esto identifica de manera única un IPF Process Flow Definición dentro de un IPF Solution. Se implementa/igual a la Tipo de entidad parte de la ID de persistencia.
¿Quién especifica este valor?
Según Tipo de entidad, valor de ID de Definición de Flujo se define durante la creación del flujo dentro de MPS(Nombre del flujo + versión opcional).
Ejemplo
Dentro de los ejemplos a continuación de un ID de persistencia, la sección resaltada captura el ID de Definición de Flujo sección.
Unversioned:
PaymentInitiation|abc-123-ef-456
Versionado:
PaymentExecutionv1|abc-123-ef-456
Comentarios del desarrollador
|
ID de Definición de Flujo se asume que es único en un IPF Solution. Existe una capacidad para la superposición de datos si diferentes IPF Services dentro de un solo IPF Solution tener el mismo ID de Definición de Flujo. Por ejemplo, el ODS almacena metadatos para la "definición" de cada IPF Processing Flow, que está indexado por ID de Definición de Flujo. |
Flujo Hash
flow Hash
El Flujo Hash es un valor derivado basado en un cálculo hash del IPF Process Flow Definición en el momento de la compilación. Se añade a cada Domain Event durante la persistencia.
Se utiliza para comparar la versión de tiempo de ejecución "actual" de un IPF Process Flowcontra el valor compilado "original". Esto puede indicar si se han realizado o no cambios posteriores en la topología de los flujos desde el procesamiento de una transacción dada, y por lo tanto proporcionar una advertencia de que la representación gráfica no será precisa.__
ID de comando
command Id
El ID de comando es un identificador compuesto en un comando que se envía a un actor Akka. Consiste en un Nombre de Comando,ID de entrada y ID de Mensaje Físico. El ejemplo más común en IPF es la presentación de un Input a un IPF Processing Flow. La abstracción de Input se convierte en un Command a través del IPF Processing Flow Input Gateway, durante el cual el ID de comando se construye a partir de los valores asociados en el Input.
El ID de comando identifica de manera única un Command en el ámbito de un dado ID de persistencia. También es la base para Idempotencia de Comandos, que protege contra efectos secundarios duplicados si se envían Comandos duplicados a un IPF. Process Flow.
¿Quién especifica este valor?
El IPF Processing Flow Input Gateway es responsable de crear esto basado en los valores pasados al Input.
La creación es "segura", utilizando por defecto UUID (V4) si no se proporciona.
Unicidad
Único dentro de un ID de persistencia.
Ejemplo
De la forma <Command Name>|<ID de entrada>|<ID de Mensaje Físico>
HandleFraudResponse|abc-123-def-456|jms-id-444-55-666
Input. ID
input.id
El campo id en un Input representa el objetivo ID de persistencia del Flujo de Procesamiento IPF para el cual se destina la Entrada.
En el caso de que una Instrucción de entrada llegue a IPF para comenzar el procesamiento (por ejemplo, un pain. 001 desde un canal) el id se trata como el esperado ID de entidad, con el asociado Tipo de entidad derivado internamente por el IPF Processing Flow Input Gateway.
En el caso de que se envíe una Respuesta de entrada a un Flujo de Procesamiento IPF, por ejemplo, una respuesta de un sistema de Filtrado de Sanciones para un pago existente, el id puede ser:
-
El completo ID de persistencia del flujo de procesamiento de IPF objetivo.
-
Solo el ID de entidad, en cuyo caso el asociado Tipo de entidad se deriva internamente.
¿Quién especifica este valor?
El IPF application será responsable de establecer el valor en el Input. Estos valores probablemente se tomarán del Processing Context actual y/o de un mensaje externo.
Unicidad
La misma semántica que ID de entidad y ID de persistencia.
Ejemplo
Dado un abajo ID de persistencia, el caso de uso 1 indica que se puede utilizar el valor completo.
PaymentInitiation|abc-123-ef-456
Dado un abajo ID de persistencia, el caso de uso 2 indica que solo los resaltados ID de entidad se debe proporcionar el componente.
PaymentInitiation|abc-123-ef-456
ID de entrada
input Id
An ID de entrada es un identificador opcional en un Input. Sirve para asociar el Input con una identidad funcional. Si está presente, el ID de entrada la propiedad internamente está mapeada a la en la base subyacente ID de comando, contribuyendo a Command Idempotency.
Si un Flujo de Procesamiento IPF ha procesado con éxito un Comando, y a continuación se envía un Comando posterior con el mismo ID de entrada(pero diferente ID de Mensaje Físico) el Flujo de Procesamiento IPF devolverá el resultado original que se obtuvo cuando se procesó el Comando original.
Las opciones comunes para este valor incluyen identificadores centrados en el negocio, como un pago.ID de transacción.
¿Quién especifica este valor?
El IPF application el desarrollador es responsable de proporcionar el ID de entrada valores según se deseen durante la construcción de un Input. El ID de entrada el valor se llena más comúnmente a partir de un identificador comercial apropiado en el Mensaje Externo relacionado.
Comentarios del desarrollador
|
ID de entrada se hace referencia tanto a los conceptos de Input como de Command. Dado que un Input es realmente solo una fachada sobre un Command, este último siendo un concepto más formal.- podríamos hacer bien en consolidar la terminología. No confunda Input. ID con ID de entrada. |
ID de Mensaje Físico
physical Message Id
Complementando el ID de entrada, el ID de Mensaje Físico es un identificador Input opcional que puede ser utilizado para proporcionar un mayor control sobre la Idempotencia del Comando.
Si un Flujo de Procesamiento IPF ha procesado con éxito un Comando, y se envía un Comando subsiguiente con el mismo ID de entrada AND ID de Mensaje Físico entonces el Flujo devolverá una respuesta indicando que el Comando fue un duplicado. Si physicalMessageId no se proporciona (o no es igual), entonces el Flujo de Procesamiento IPF devolverá el resultado original que se devolvió cuando se procesó el Comando original.
Los candidatos para este valor se toman a menudo de identificadores de mensajes específicos de transporte, como un JMSMessage ID.
El enfoque principal de este identificador es ayudar a diferenciar entre reintentos relacionados con la infraestructura y reintentos funcionales.
¿Quién especifica este valor?
El IPF Application El desarrollador es responsable de completar esto con un valor apropiado. A menudo, esto provendrá de los metadatos técnicos del Mensaje Externo relacionado.
Unicidad
Requerido único por Input para dado ID de persistencia.
ID de Flujo de Llamadas
calling Flow Id
El ID de Flujo de Llamadas es una referencia opcional a la ID de persistencia de una instancia anterior de IPF Processing Flow.
Por ejemplo, si el flujo A llama al flujo B, entonces el flujo B Aggregate (y las invocaciones de Action subsiguientes) tendrán una referencia adicional al ID de persistencia de flujo A.
Esto es para que el flujo B pueda "responder" al flujo A cuando sea necesario.- sin requerir puntos de datos específicos de la aplicación adicional, o al exigir que los flujos compartan un común ID de entidad.
¿Quién especifica este valor?
El ID de Flujo de Llamadas se deriva automáticamente del Flujo de Procesamiento IPF siempre que los dos flujos faciliten el Causado Por Event ID patrón.
Se actualiza en el Aggregate y se proporciona a todas las Actions subsiguientes a través de sus respectivas instancias de Action Parameters.
Iniciando ID
initiating Id
Comentarios del desarrollador
Probable superposición con ID de Flujo de Llamadas y Causado Por Event ID
Causado Por Event ID
caused By Event Id
El Causado Por Event ID es la captura de un precedente lógico Event ID. Es decir, "cuál anterior Domain Event relacionado con mi Unit Of Work causó la actual Acción. La Acción siendo la emisión de un Comando, API solicitud y/o probable persistencia de un Domain Event.
Esto podría ser un Flujo de Procesamiento IPF lateralmente invocando otro, por ejemplo, la Iniciación de Pago llamando a la Ejecución de Pago. También podría utilizarse en un contexto vertical (padre-hijo) como un único flujo Masivo generando muchos flujos de Instrucción hijos.
El *Causado Por Event ID*s son los enlaces de un solo paso que forman la cadena de orden causal a través de la eventIds para un dado Unit Of Work.
Se utilizan para ayudar a proporcionar un sentido de orden causal dentro de un _distribuido_IPF Solution, a través del uso de una marca de tiempo de Lamport.
Existen advertencias sobre el uso de Causado Por Event ID, y en términos generales, si un IPF application el desarrollador desea obtener un gráfico ordenado causal de datos relacionados con un conocido Unit of Work deben referirse a la Punto de control funcionalidad.
¿Quién especifica este valor?
El IPF application El desarrollador es responsable tanto de proporcionar como de consumir este punto de datos para el IPF. API Solicite, y luego propágelo al Input.
Comentarios del desarrollador
El <<causedByEventId>> se transmite entre IPF services en el IPF API Solicite cargas útiles utilizando el Custom_Mapa de contexto de soporte_ con acceso a literales de cadena. Este enfoque es demasiado manual y demasiado laxo para una función principal. La representación de la Causado Por Event ID dentro de la core IPF API Las solicitudes deben ser representadas como ciudadanos de primera clase, similar a Processing Context. |
Identificadores de Aplicación
ID de correlación
correlation Id
El ID de correlación es un identificador derivado que asociará de manera única una solicitud enviada desde un Conector IPF con una respuesta recibida de manera asíncrona.
El ID de correlación es la clave para la entrada almacenada por el componente de aplicación Correlation Service. El valor de la entrada es el Processing Context que contiene el conjunto de identificadores IPF internos.Unit of Work ID etc). Como tal, el ID de correlación es el "enlace" de una respuesta asíncrona para "reanudar" el procesamiento interno de un Unit of Work.
¿Quién especifica este valor?
El IPF application El desarrollador es responsable de configurar los Connectors de Envío y Recepción con las funciones apropiadas para derivar el ID de correlación de Request y Response payloads.
ID de mensaje
message Id
A ID de mensaje identifica de manera única un Mensaje Externo dentro del alcance de un solo Unit of Work.
ID de Solicitud Externa
external Request Id
Este identificador está presente en las API de Intercambio de Mensajes IPF estándar, por ejemplo, Solicitud de Iniciación de Pago, Solicitud de Ejecución de Pago, etc.
Su uso previsto es identificar de manera única un Message, para apoyar API idempotencia de nivel.
Un patrón común es derivar el ID de Solicitud del Cliente desde el ID de Solicitud Externa en el mensaje original Instruction.
Ubicaciones comunes
-
Intercambio de Mensajes IPF API Solicitudes
-
Intercambio de Mensajes IPF API Respuestas
Estructura de Datos del Mensaje ID
mds Id
El MDS Object ID identifica de manera única y MDS punto de datos relacionado con un Unit of Work. MDS los objetos pueden ser consultados por ID por el ODS, y MDS puede relacionarse con otros MDS como una relación entre padre e hijo.
Por ejemplo, asociando Credit Transfer Transactions con un Payment Instruction padre.
Sinónimos y conceptos relacionados
-
mds Object Container.id (Dentro de IPF Processing Data)
-
mds Object Container.parent Id (Dentro de IPF Processing Data)
¿Quién especifica este valor?
IPF genera y asigna automáticamente este valor como Process Flow Domain Events conteniendo MDS objetos.
Operational Data Store Identificadores
ODS ID de objeto
ods Object Id
El ODS El ID de objeto es un identificador interno (clave primaria) utilizado para objetos de datos persistidos en el ODS.
Process Object ID
process Object Id
A Process Object ID identifica de manera única un objeto de datos de tipo Process dentro de un Unit of Work, dentro del contexto de identificadores generados por IPF.
Esto se denomina uniqueId al completar los Contenedores de Datos dentro del IPF Processing Data ingestión API.
ODS utiliza este valor como un *idempotencyKey* y lo presenta como <<processObjectId>> en el ODS Inquiry API.
El Contexto de ProcesamientoPunto de control se refiere a este valor.
¿Quién especifica este valor?
Este valor se deriva internamente por el IPF application componentes principales y enriquecido con los datos emitidos desde IPF to ODS.
ISO20022 Identificadores de Mensajes
Esta sección detalla algunos identificadores específicos de pago que ocurren comúnmente en el ISO20022 Intercambios de mensajes. Esta lista no es exhaustiva, el detalle completo se puede encontrar en el oficial Documentación ISO20022
ID de transacción
transaction Id
Identificación única, asignada por el primer agente instructor, para identificar de manera inequívoca la transacción que se transmite, sin cambios, a lo largo de toda la cadena interbancaria.
Uso: La identificación de la transacción puede ser utilizada para la conciliación, el seguimiento o para vincular tareas relacionadas con la transacción a nivel interbancario.
Uso: El agente instructor debe asegurarse de que la identificación de la transacción sea única durante un período previamente acordado.
Ubicaciones comunes
-
Secciones de transacción de mensajes comunes como Custom Transferencia de Crédito (Pacs. 008/Pacs. 009).
¿Quién especifica este valor?
Este campo debe ser completado en el mensaje de Transferencia de Crédito apropiado antes de ser transmitido a un esquema o CSM.
Para la mayoría de los escenarios comunes de IPF, esto ocurre durante el procesamiento de la Ejecución de Pagos. El IPF application El desarrollador es responsable de establecer este valor al construir el mensaje de Transferencia de Crédito. A menudo, puede derivarse de uno o más campos de una solicitud de Iniciación de Pago (pain. 001), o un UUID aleatorio.
Unicidad
Diferentes esquemas exigen diferentes duraciones para las que el transactionId puede asumirse que es único para apoyar futuras verificaciones, como una comprobación de duplicados.
en los pagos de Transferencia de Crédito S. E. P. A. Instantánea, las solicitudes de Reembolso de Pago pueden ser ofrecidas hasta 13 meses después de que un pago haya sido liquidado. Los reembolsos incluyen una referencia a un pago original por originalTransactionId referencia.
Referencia Única de Transacción de Extremo a Extremo (UETR)
UETR
Identificador único universal para proporcionar una referencia de extremo a extremo de una transacción de pago.
Ubicaciones comunes
-
Sección de Identificación de Pago de bloques de transacción en mensajes de pago relacionados.
¿Quién especifica este valor?
El valor está presente opcionalmente en una Solicitud de Inicio de Pago (por ejemplo,pain. 001), por lo que puede ser proporcionado por un canal o cliente.
Ejemplo
==== Comentarios del desarrollador
'''
=== Identificación de extremo a extremo [[endToEndId]]
_end To End Id_
Identificación única asignada por la parte iniciadora para identificar de manera inequívoca la transacción. Esta identificación se transmite, sin cambios, a lo largo de toda la cadena de extremo a extremo.
Uso: La identificación de extremo a extremo puede ser utilizada para la conciliación o para vincular tareas relacionadas con la transacción. Puede incluirse en varios mensajes relacionados con la transacción.
==== Sinónimos y conceptos relacionados
//TODO
==== Ubicaciones comunes
* Sección de Identificación de Pago de los bloques de transacción en los mensajes de pago relacionados.
==== ¿Quién especifica este valor?
El cliente proporciona este valor en la Solicitud de Inicio de Pago como parte del bloque de Identificación de Pago de la transacción.
datos.
==== Unicidad
Identificación única según la parte iniciadora.
==== Ejemplo
//TODO
==== Comentarios del desarrollador
//TODO
'''
=== ID de mensaje [[paymentMessageId]]
_message Id_
Referencia punto a punto, según lo asignado por la parte instructora, y enviada a la siguiente parte en la cadena para identificar de manera inequívoca el mensaje.
Uso: La parte instructora debe asegurarse de que MessageIdentification sea único por cada parte instruida durante un período previamente acordado.
==== Sinónimos y conceptos relacionados
* _msg Id_
==== Ubicaciones comunes
La mayoría de los individuales _Message Definition s_ tener un <<messageId>> campo. Dentro de IPF a veces se utiliza para:
* _Verificación de duplicados_- como parte de los criterios de hash de campo.
* _Idempotencia de Comando_- como fuente para <<inputId>> junto a <<physicalMessageId>>.
* <<clientRequestId>> fuente.
==== ¿Quién especifica este valor?
El IPF application es responsable de establecer estos valores en los Mensajes que envía a sistemas externos.
==== Unicidad
Funcionalmente, este valor debe ser único; las implementaciones del esquema relajan este requisito al permitir la unicidad dentro de
un período preacordado.
==== Ejemplo
//TODO
==== Comentarios del desarrollador
//TODO