ES2951835T3 - Sistema y método para establecer el procesamiento de solicitudes común - Google Patents
Sistema y método para establecer el procesamiento de solicitudes común Download PDFInfo
- Publication number
- ES2951835T3 ES2951835T3 ES19764336T ES19764336T ES2951835T3 ES 2951835 T3 ES2951835 T3 ES 2951835T3 ES 19764336 T ES19764336 T ES 19764336T ES 19764336 T ES19764336 T ES 19764336T ES 2951835 T3 ES2951835 T3 ES 2951835T3
- Authority
- ES
- Spain
- Prior art keywords
- request
- response
- api
- establishment system
- processor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 106
- 238000012545 processing Methods 0.000 title description 38
- 230000004044 response Effects 0.000 claims abstract description 189
- 238000012360 testing method Methods 0.000 claims abstract description 132
- 238000004088 simulation Methods 0.000 claims description 41
- 238000013523 data management Methods 0.000 claims description 4
- 238000004891 communication Methods 0.000 description 18
- 230000002688 persistence Effects 0.000 description 12
- 238000012546 transfer Methods 0.000 description 12
- 230000006870 function Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 230000008901 benefit Effects 0.000 description 5
- 230000005540 biological transmission Effects 0.000 description 5
- 238000004519 manufacturing process Methods 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000036541 health Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000009467 reduction Effects 0.000 description 2
- 238000012552 review Methods 0.000 description 2
- 238000013024 troubleshooting Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012806 monitoring device Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computing Systems (AREA)
- Computer And Data Communications (AREA)
- Debugging And Monitoring (AREA)
- Communication Control (AREA)
- Exchange Systems With Centralized Control (AREA)
Abstract
Se divulga un método. Un sistema de establecimiento de implementación puede recibir un primer mensaje que incluye un modelo de método de solicitud y una plantilla de un procesador de solicitudes. El sistema de establecimiento de implementación puede generar al menos una llamada API de prueba basada en el modelo del método de solicitud y la plantilla. El sistema de establecimiento de implementación puede entonces transmitir al menos una llamada API de prueba al procesador de solicitudes. El sistema de establecimiento de implementación puede recibir al menos una respuesta basada en al menos una llamada API de prueba desde el procesador de solicitudes. El sistema de establecimiento de implementación puede evaluar al menos una respuesta. El sistema de establecimiento de implementación puede generar una notificación de respuesta basada en al menos una respuesta. El sistema de establecimiento de implementación puede transmitir la notificación de respuesta al procesador de solicitudes. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Sistema y método para establecer el procesamiento de solicitudes común
Referencias cruzadas a solicitudes relacionadas
Ninguna.
Antecedentes
En los sistemas y métodos actuales, los mensajes de solicitudes de los sistemas de solicitudes a los procesadores de solicitudes se envían a través de una plataforma de formato de solicitudes. Por ejemplo, un sistema de solicitudes, que es un ordenador proveedor de recursos puede transmitir un mensaje de solicitud solicitando autorización a través de una plataforma de formato de solicitudes al procesador de solicitudes de un ordenador de entidad autorizadora. Después de recibir las solicitudes desde los sistemas de solicitudes, la plataforma de formato de solicitudes puede generar solicitudes formateadas para los procesadores de solicitudes de acuerdo con las especificaciones de una API de procesamiento de solicitudes común. La misma API de procesamiento de solicitudes común puede usarse en la plataforma de formato de solicitudes para comunicarse con todos los procesadores de solicitudes de acuerdo con un formato específico.
Sin embargo, al hacerlo, los procesadores de solicitudes deben codificarse conforme a la especificación de la API de la plataforma de formato de solicitudes. Típicamente, esto se realiza al configurar manualmente las llamadas a la API entre el procesador de solicitudes y la plataforma de formato de solicitudes, y luego el diagnóstico y solución de problemas. Para hacer esto, los usuarios del procesador de solicitudes proporcionan los detalles del punto de extremo a los usuarios de la plataforma de formato de solicitudes, generalmente a través del correo electrónico. Los usuarios del procesador de solicitudes luego proporcionan a los usuarios de la plataforma de formato de solicitudes los servicios de la API que desean usar. Los usuarios del procesador de solicitudes, luego, codifican su sistema para poder recibir llamadas en un formato correspondiente a la API de procesamiento de solicitudes común. Los usuarios del procesador de solicitudes envían un correo electrónico o contactan de cualquier otra manera a los usuarios de la plataforma de formato de solicitudes, lo que indica que están listos para recibir llamadas a la API. Después de coordinar fechas y horarios, la plataforma de formato de solicitudes puede transmitir llamadas de la API al procesador de solicitudes. El procesador de solicitudes puede responder a las llamadas de la API. Los usuarios de la plataforma de formato de solicitudes entonces pueden determinar si las llamadas a la API se recibieron en el formato correcto. Los usuarios de la plataforma de formato de solicitudes entonces pueden analizar con los usuarios del procesador de solicitudes para decidir cómo configurar el procesador de solicitudes para que responda correctamente a las llamadas a la API.
Una vez que el procesador de solicitudes se configura, pueden tener lugar muchas más rondas de llamadas y respuestas a la API. Después de que el procesador de solicitudes genera correctamente las respuestas, los usuarios del procesador de solicitudes pueden pedir la certificación desde la plataforma de formato de solicitudes.
Este proceso tiene varias desventajas. Una de ellas es que la plataforma de formato de solicitudes necesita tener un equipo de soporte e integración especializado para incorporar los detalles del procesador de solicitudes en la plataforma de formato de solicitudes, y para iniciar llamadas personalizadas a la API para probar las respuestas del procesador de solicitudes.
0tro problema es que los procesadores de solicitudes que se programan para una API específica tienen una alta dependencia de la plataforma de formato de solicitudes para incorporar y probar las respuestas del procesador de solicitudes contra esa API.
Estos problemas conducen a una menor eficiencia, un mayor tiempo de comercialización y una solución con errores y problemas de gestión de proyectos debido a las interdependencias en los sistemas externos que debe cumplir un procesador de solicitudes. Realizar esto con múltiples procesadores de solicitudes multiplica significativamente el problema.
El documento US 2017/353375 A1 describe un método implementado por ordenador para monitorear los puntos de extremo de una API.
El documento US 2015/128103 A1 describe un sistema y método para proporcionar una plataforma de servicio de API.
Las modalidades de la invención abordan estos y otros problemas de forma individual y colectiva.
Resumen
Las modalidades de la invención resuelven estos problemas al permitir que los procesadores de solicitudes establezcan automáticamente implementaciones para responder a las solicitudes.
De acuerdo con un primer aspecto de la invención, se proporciona un método implementado por ordenador, como se define en la reivindicación adjunta 1.
De acuerdo con un segundo aspecto de la invención, se proporciona un sistema de establecimiento de implementación, como se define en la reivindicación adjunta 7.
Estas y otras modalidades se describen con mayor detalle a continuación, con referencia a las figuras y la descripción detallada.
Breve descripción de las figuras
La Figura 1 muestra un diagrama de bloques de un sistema para el procesamiento de solicitudes de acuerdo con una modalidad de la invención.
La Figura 2 muestra un diagrama de bloques de un primer procesador de solicitudes de acuerdo con una modalidad de la invención.
La Figura 3 muestra un diagrama de bloques de un sistema de establecimiento de implementación de acuerdo con una modalidad de la invención.
La Figura 4 muestra un diagrama de flujo que ilustra un método para establecer una implementación para un procesador de solicitudes de acuerdo con una modalidad de la invención.
La Figura 5 muestra un diagrama de flujo que ilustra un método alternativo para establecer una implementación para un procesador de solicitudes de acuerdo con una modalidad de la invención.
Descripción detallada
Antes de describir las modalidades de la invención, algunos términos pueden describirse con más detalle. Una "interfaz de programación de aplicaciones" o "API" puede ser un conjunto de definiciones, protocolos y herramientas para construir y mantener programas y aplicaciones. Una API puede ser para un ordenador servidor, un sistema basado en red, un sistema operativo, un sistema de bases de datos, hardware informático y/o programas informáticos. Una "API de procesamiento de solicitudes común" puede ser cualquier API que se configure para procesar solicitudes (por ejemplo, formatear solicitudes, actuar sobre solicitudes, responder a solicitudes, etc.) que es común entre múltiples entidades. Por ejemplo, una API de procesamiento de solicitudes común puede implementarse mediante una plataforma de formato de solicitudes que recibe y formatea solicitudes, así como también mediante múltiples procesadores de solicitudes que reciben, actúan y responden a solicitudes formateadas, de manera que la plataforma de formato de solicitudes puede comunicarse de manera similar (por ejemplo, en un formato similar) con los múltiples procesadores de solicitudes.
Las "Especificaciones" pueden incluir uno o más requerimientos y/o detalles de algo. En algunas modalidades, las especificaciones de una interfaz de programación de aplicaciones (API) pueden incluir requerimientos para rutinas, estructuras de datos, clases de objetos, variables y/o llamadas remotas. Por ejemplo, las especificaciones de una API pueden indicar que una rutina específica se ejecuta en las solicitudes para generar solicitudes formateadas. En otro ejemplo, las especificaciones de una API pueden indicar una estructura o formato particular que debe usarse al generar una respuesta a una solicitud formateada.
Una "implementación" puede ser un programa o componente de programa que se considera mediante un sistema de establecimiento de implementación como completamente funcional y completo. Puede existir más de una implementación para una especificación.
Un "componente simulador" es un fragmento de código o un programa que se usa como sustituto de alguna otra funcionalidad de programación. En algunas modalidades, el componente simulador puede ser una implementación incompleta. El componente simulador puede configurarse y/o alterarse para convertirse en una implementación. Por ejemplo, un procesador de solicitudes puede usar un componente simulador para generar respuestas que respondan a una solicitud, en donde el componente simulador puede generar una respuesta incorrecta. Si el componente simulador generó una respuesta incorrecta, entonces puede configurarse el componente simulador para que no genere la respuesta incorrecta. En algunas modalidades, si el componente simulador no genera respuestas incorrectas, puede considerarse que el simulador es una implementación.
Un "modelo del método de solicitud" puede ser un modelo para el procesamiento de solicitudes. El modelo del método de solicitud puede incluir al menos un método de solicitud. En algunas modalidades, el método de solicitud puede incluir los servicios de la API que el procesador de solicitudes admite, una secuencia de servicios de la API que el procesador de solicitudes admite los campos de la API que el procesador de solicitudes admite como obligatorios y/o lo mo
opcionales. En algunas modalidades, diferentes procesadores de solicitudes pueden asociarse con diferentes modelos de métodos de la solicitud. Por ejemplo, un modelo del método de solicitud puede incluir un método de solicitud relacionado con una transferencia bancaria, con los servicios de la API de "procesamiento de pagos", "servicio de reemboIso" y "servicio de estado". Puede usarse cualquier método de solicitud adecuado. Puede usarse cualquier servicio API adecuado. En algunas modalidades, el método de solicitud puede referirse a pagos, atención sanitaria, servicios bancarios, comercio minorista, envíos, servicios públicos, gestión de datos, educación o fabricación.
"Campos" puede referirse a conjuntos divisibles de datos en ubicaciones fijas o conocidas. Por ejemplo, un mensaje puede incluir uno o más campos diferentes. Cada campo puede tener un tipo y/o una ubicación. Un tipo de campo podría ser, por ejemplo, un identificador para un sistema de solicitud, mientras que el campo podría incluir "Resource_Provider_A". Una ubicación del campo puede ser, por ejemplo, el primer campo al comienzo de un mensaje. El campo puede ser interpretable debido a su ubicación conocida. Un campo puede ser de longitud fija o variable. Si un campo tiene una longitud fija, el campo será fácilmente interpretable, ya que siempre tendrá un número específico de caracteres. En algunas modalidades, pueden agregarse ceros iniciales (u otro valor) a un campo para que tenga la longitud fija adecuada. Si un campo tiene una longitud variable, el campo puede interpretarse desde otros campos en un mensaje mediante el uso de un separador (por ejemplo, uno o más espacios, uno o más signos de puntuación o cualquier otro carácter).
Un "formato" puede hacer referencia al arreglo, organización, tamaño, forma y/o estructura de algo. Por ejemplo, un formato de un mensaje puede incluir un número de campos en el mensaje, tamaños de los campos en el mensaje, tipos de campos en el mensaje, ubicación (por ejemplo, el arreglo) de los campos en el mensaje, separación entre los campos y en otras ubicaciones del mensaje, y/o puntuación en y entre los campos y en otras ubicaciones del mensaje.
Un "identificador" puede referirse a cualquier combinación de letras, números y/o símbolos que se usan para identificar de manera única algo. Un identificador puede asignarse aleatoriamente, consecutivamente, o de acuerdo con cualquier patrón o algoritmo. En algunas modalidades, un sistema de solicitudes puede asociarse con un identificador que puede usarse para identificar el sistema de solicitudes ante una plataforma de formato de solicitudes.
Una "solicitud" puede ser cualquier mensaje que se envía entre entidades que solicitan algo. Una solicitud puede originarse en una entidad y enviarse a otra entidad para solicitar algo. En algunas modalidades, una solicitud puede solicitar información, datos, acción, inacción, servicios, aplicaciones, y similares. Una solicitud puede transmitirse mediante cualquier método adecuado, tal como, por ejemplo, a través de una red. Una solicitud puede incluir cualquier combinación de letras, números y/o símbolos que puedan interpretarse en la entidad receptora. En algunas modalidades, una solicitud puede cifrarse, resumirse criptográficamente, codificarse o enmascararse de cualquier otra manera. Una solicitud puede adoptar la forma, por ejemplo, de una llamada a la API. Una solicitud puede tener cualquier formato. Una "solicitud formateada" puede ser una solicitud que se ha convertido a un formato específico.
Un "procesador de solicitudes" puede ser una entidad (por ejemplo, un sistema o un ordenador servidor) que incluye uno o más componentes electrónicos que pueden procesar solicitudes que se reciben desde otra entidad (por ejemplo, un sistema, dispositivo u ordenador servidor). Por ejemplo, un procesador de solicitudes puede ser un dispositivo informático que incluye al menos un procesador que se acopla a una memoria que almacena instrucciones o código para que se ejecute mediante el procesador. Un procesador de solicitudes puede proporcionar capacidades de comunicación remota a una red. Un procesador de solicitudes puede configurarse para transmitir y recibir datos o comunicaciones hacia y desde otros dispositivos. En algunos ejemplos, un proveedor de servicios puede operar un procesador de solicitudes.
Un "sistema de solicitud" puede ser una entidad (por ejemplo, un sistema o dispositivo) que incluye uno o más componentes electrónicos (por ejemplo, un chip) que pueden comunicar solicitudes a otra entidad (por ejemplo, un sistema, dispositivo u ordenador servidor). Por ejemplo, un sistema de solicitudes puede ser un dispositivo informático que incluye al menos un procesador que se acopla a una memoria que almacena instrucciones o código para su ejecución mediante el procesador. Un sistema de solicitudes puede proporcionar capacidades de comunicación remota a una red. Un sistema de solicitudes puede configurarse para transmitir y recibir datos o comunicaciones hacia y desde otros dispositivos. Un sistema de solicitudes puede tener la forma de un ordenador, un dispositivo de acceso (por ejemplo, un dispositivo de punto de venta), un dispositivo móvil tal como un teléfono móvil (por ejemplo, un teléfono inteligente, un teléfono celular, etc.), tabletas, reproductores de medios portátiles, dispositivos de asistente digital personal (PDA), dispositivos informáticos portátiles (por ejemplo, relojes), dispositivos de monitoreo de salud, dispositivos de lectura electrónica (por ejemplo, un lector de tarjetas), un dispositivo del Internet de las cosas (IoT), etc., o en forma de una tarjeta (por ejemplo, una tarjeta inteligente) o un llavero, etc. Los ejemplos de sistemas de solicitudes también pueden incluir dispositivos informáticos portátiles (por ejemplo, ordenadores portátiles, miniportátiles, portátiles ultradelgados, etc.). Un sistema de solicitudes también puede tener la forma de un vehículo (por ejemplo un automóvil) o integrarse como parte de un vehículo (por ejemplo, un
Un "recurso" puede ser cualquier activo tangible o intangible. Los recursos ilustrativos incluyen dinero, mano de obra, datos, programas, bienes, información, servicios y similares.
Una "respuesta" puede ser cualquier mensaje que se envíe entre las entidades que responden a una solicitud. Una respuesta puede originarse desde una entidad y enviarse a otra entidad para proporcionar una respuesta, resultado o reacción a una solicitud, aunque cada solicitud no necesariamente necesita o tiene una respuesta. Una respuesta puede transmitirse mediante cualquier método adecuado, tal como, por ejemplo, a través de una red. En algunas modalidades, una respuesta puede incluir información, notificaciones, informes, datos, acción, inacción, servicios, aplicaciones y similares. Una respuesta puede incluir cualquier combinación de letras, números y/o símbolos que puedan interpretarse en la entidad receptora. En algunas modalidades, una respuesta puede cifrarse, resumirse criptográficamente, codificarse o enmascararse de cualquier otra manera. Una respuesta puede tener cualquier formato. Una "respuesta formateada" puede ser una respuesta que se ha generado en un formato específico.
Un "ordenador servidor" puede incluir un poderoso ordenador o un conglomerado de ordenadores. Por ejemplo, el ordenador servidor puede ser un ordenador central grande, un clúster de miniordenador o un grupo de servidores que funcionan como una unidad. En un ejemplo, el ordenador servidor puede ser un servidor de base de datos que se acopla a un servidor web. El ordenador servidor puede acoplarse a una base de datos y puede incluir cualquier hardware, programa, otra lógica o combinación de las anteriores para atender las solicitudes de uno o más ordenadores cliente. El ordenador servidor puede comprender uno o más aparatos informáticos y pueden usar cualquiera de una variedad de estructuras informáticas, arreglos y compilaciones para atender las solicitudes de uno o más ordenadores cliente. Una plataforma de formato de solicitudes puede ser un ejemplo de un ordenador servidor.
Un "punto de extremo" puede ser un extremo de un canal de comunicación. En algunas modalidades, el punto de extremo puede ser un localizador de recursos universal (URL) que se usa para comunicarse con una API. En otras modalidades, el punto de extremo puede ser el lugar al que llegan las solicitudes y otras llamadas de la API para su procesamiento.
A. Sistemas
A continuación, se describen los sistemas. Las capacidades de los sistemas se describen con más detalle en la sección de métodos.
La Figura 1 muestra un diagrama de bloques de un sistema 100 que comprende un número de componentes de acuerdo con una modalidad de la invención. El sistema 100 comprende un sistema de solicitudes 104, una plataforma de formato de solicitudes 106, un sistema de establecimiento de implementación 102, un primer procesador de solicitudes 108A, un segundo procesador de solicitudes 108B y un enésimo procesador de solicitudes 108C.
El sistema de solicitudes 104 puede estar en comunicación operativa con la plataforma de formato de solicitudes 106. La plataforma de formato de solicitudes 106 puede acoplarse operativamente al sistema de establecimiento de implementación 106F. El sistema de establecimiento de implementación 102 puede estar en comunicación operativa con el primer procesador de solicitudes 108A, el segundo procesador de solicitudes 108B y el enésimo procesador de solicitudes 108C.
El sistema de establecimiento de implementación 106F, el sistema de solicitudes 104, la plataforma de formato de solicitudes 106, el primer procesador de solicitudes 108A, el segundo procesador de solicitudes 108B y el enésimo procesador de solicitudes 108C, pueden estar en comunicación operativa entre sí a través de cualquier canal de comunicación adecuado o red de comunicaciones. Las redes de comunicaciones adecuadas pueden ser cualquier combinación de las siguientes: una interconexión directa; Internet; una Red de Årea Local (LAN); una Red de Årea Metropolitana (MAN); una misión operativa como Nodos en Internet (0MNI); una conexión personalizada segura; una Red de Årea Amplia (WAN); una red inalámbrica (por ejemplo, que emplea protocolos como, pero no limitados a, Protocolo de Aplicación Inalámbrica (WAP), I-mode y/o similares); y/o similares. Los mensajes entre ordenadores, redes y dispositivos pueden transmitirse mediante el uso de protocolos de comunicaciones seguros tales como, pero no limitados a, el Protocolo de Transferencia de Archivos (FTP); el Protocolo de Transferencia de Hipertexto (HTTP); el Protocolo de Transferencia de Hipertexto Seguro (HTTPS), la Capa de Conexión Segura (SSL), IS0 (por ejemplo, IS0 8583) y/o similares.
Por simplicidad de ilustración, se muestra un cierto número de componentes en la Figura 1. Se entiende, sin embargo, que las modalidades de la invención pueden incluir más de uno de cada componente. Por ejemplo, puede haber más de un sistema de solicitudes 104. En algunas modalidades, puede haber miles de sistemas de solicitudes 104.
El sistema de solicitudes 104 puede ser un sistema o dispositivo capaz de comunicarse con la plataforma de formato de solicitudes 106. El sistema de solicitudes 104 puede transmitir solicitudes a la plataforma de formato de solicitudes 106. Las solicitudes pueden estar en cualquier formato adecuado capaz de recibirse mediante la plataforma de formato de solicitudes 106. En algunas modalidades, el sistema de solicitudes 104 puede asociarse con un identificador del sistema de solicitudes.
La plataforma de formato de solicitudes 106 puede ser capaz de recibir solicitudes desde el sistema de solicitudes 104. La solicitud del sistema de solicitudes 104 puede estar en un formato que cumpla con la especificación de la plataforma de formato de solicitudes 106. En algunas modalidades, la plataforma de formato de solicitudes 106 puede estar en comunicación operativa con el primer procesador de solicitudes 108A, el segundo procesador de solicitudes 108B y el enésimo procesador de solicitudes 108C. La plataforma de formato de solicitudes 106 puede realizar cualquiera de las funciones que se describieron adicionalmente en la solicitud de patente de Estados Unidos 15/355,453, presentada el 18 de noviembre de 2016.
El sistema de establecimiento de implementación 102 puede asociarse con la plataforma de formato de solicitudes 106. En algunas modalidades, el sistema de establecimiento de implementación 102 puede ser un ordenador servidor. El sistema de establecimiento de implementación 102 puede ser capaz de recibir datos desde el primer procesador de solicitudes 108A, y puede ser capaz de transmitir datos al primer procesador de solicitudes 108A.
En algunas modalidades, el sistema de establecimiento de implementación 102 puede ser capaz de recibir un primer mensaje que incluye un modelo del método de solicitud y una plantilla desde el primer procesador de solicitudes 108A. El sistema de establecimiento de implementación 102 puede ser capaz de generar al menos una llamada de prueba a la API en función del modelo del método de solicitud y la plantilla. El sistema de establecimiento de implementación 102 puede ser capaz de transmitir la al menos una llamada de prueba a la API al primer procesador de solicitudes 108A.
Además, el sistema de establecimiento de implementación 102 puede ser capaz de recibir al menos una respuesta en función de la al menos una llamada de prueba a la API desde el primer procesador de solicitudes 108a . El sistema de establecimiento de implementación 102 puede entonces ser capaz de evaluar la al menos una respuesta y generar una notificación de respuesta en función de la al menos una respuesta. El sistema de establecimiento de implementación 102 puede ser capaz de transmitir la notificación de respuesta al primer procesador de solicitudes 108A.
En otras modalidades, el sistema de establecimiento de implementación 102 puede recibir un mensaje de solicitud desde el primer procesador de solicitudes 108A. El mensaje de solicitud puede invocar el sistema de establecimiento de implementación 102 para generar un componente simulador de solicitudes del cliente y un módulo de simulación. En algunas modalidades, el sistema de establecimiento de implementación 102 puede generar el componente simulador de solicitudes del cliente. El sistema de establecimiento de implementación 102 también puede generar el módulo de simulación. En algunas modalidades, el sistema de establecimiento de implementación 102 puede transmitir el componente simulador de solicitudes del cliente al primer procesador de solicitudes 108A.
El primer procesador de solicitudes 108A, el segundo procesador de solicitudes 108B y el enésimo procesador de solicitudes 108C pueden ser ordenadores servidores. El primer procesador de solicitudes 108A puede ser capaz de recibir solicitudes desde el sistema de solicitudes 104 a través de la plataforma de formato de solicitudes 106.
En algunas modalidades, el primer procesador de solicitudes 108A puede ser capaz de integrarse en el sistema de establecimiento de implementación 102 al proporcionar los puntos de extremo del procesador de solicitudes que pueden recibir tanto las llamadas de prueba a la API, así como también las llamadas a la API. Los puntos de extremo del procesador de solicitudes pueden ser Irlos que se definen para recibir tanto las llamadas de prueba a la a Pi, así como también las llamadas a la API en un formato específico, y luego responder conforme a la especificación de la API de procesamiento de solicitudes común. El primer procesador de solicitudes 108A puede ser capaz de usar el API de procesamiento de solicitudes común. El primer procesador de solicitudes 108A puede programar código que cumpla con las especificaciones de la API de procesamiento de solicitudes común.
El primer procesador de solicitudes 108A puede transmitir el primer mensaje que incluye el modelo del método de solicitud y la plantilla al sistema de establecimiento de implementación 102. El primer procesador de solicitudes 108A puede recibir al menos una llamada de prueba a la API en función del modelo del método de solicitud y la plantilla del sistema de establecimiento de implementación 102. En algunas modalidades, después de recibir la al menos una llamada de prueba a la API, el primer procesador de solicitudes 108A puede generar al menos una respuesta en función de la al menos una llamada de prueba a la API. El primer procesador de solicitudes 108A puede entonces transmitir la al menos una respuesta al sistema de establecimiento de implementación 102. El na
notificación de respuesta en función de la al menos una respuesta del sistema de establecimiento de implementación 102.
En algunas modalidades, el primer procesador de solicitudes 108A puede ser capaz de transmitir una solicitud de certificación a la plataforma de formato de solicitudes 106. El sistema de establecimiento de implementación 102 puede determinar certificar el componente simulador de solicitudes del cliente del primer procesador de solicitudes 108A en función de al menos a la solicitud de certificación. En otras modalidades, el primer procesador de solicitudes 108A puede presentar una solicitud de asistencia al sistema de establecimiento de implementación 102 para la resolución de problemas y ayuda.
El segundo procesador de solicitudes 108B y el enésimo procesador de solicitudes 108C pueden tener características similares o diferentes al primer procesador de solicitudes 108A, y la descripción de las características comunes no necesita repetirse aquí.
La Figura 2 muestra un diagrama de bloques de un primer procesador de solicitudes 108A de acuerdo con una modalidad de la invención. El primer procesador de solicitudes 108A puede comprender un procesador 202, una interfaz de red 204, elementos de entrada/salida 206, un medio legible por ordenador 210 que comprende un componente simulador de solicitudes del cliente 21 0A y una memoria 208.
La interfaz de red 204 puede incluir una interfaz que puede permitir que el primer procesador de solicitudes 108A se comunique con ordenadores externos u otros nodos. Por ejemplo, la interfaz de red 204 puede comprender una interfaz de contacto, Bluetooth o Wi-Fi. En algunas modalidades, la interfaz de red 204 puede configurarse para permitir transmisiones seguras entre el primer procesador de solicitudes 108A y el sistema de establecimiento de implementación 102.
Los elementos de entrada/salida 206 pueden comprender cualquier dispositivo adecuado que pueda generar datos. Algunos ejemplos de elementos de entrada pueden incluir botones, pantallas táctiles, paneles táctiles, micrófonos, escáneres biométricos, etc. Los ejemplos de elementos de salida pueden incluir pantallas de visualización, altavoces y dispositivos de transmisión de datos.
El medio legible por ordenador 210 puede comprender un código, ejecutable por el procesador 202. El medio legible por ordenador 210 puede contener cualquier número de aplicaciones, módulos y código. El medio legible por ordenador 210 puede comprender una cantidad de módulos que incluyen el componente simulador de solicitudes del cliente 210A. El medio legible por ordenador 210 también puede contener código, que cuando se ejecuta por el procesador 202, puede implementar un método que comprende: transmitir un primer mensaje que incluye un modelo del método de solicitud y una plantilla a un sistema de establecimiento de implementación; recibir al menos una llamada de prueba a la API en función al modelo del método de solicitud y la plantilla del sistema de establecimiento de implementación; generar una respuesta en función a la al menos una llamada de prueba a la API; transmitir la respuesta al sistema de establecimiento de implementación; recibir, mediante el procesador de solicitudes, una notificación de respuesta en función a la respuesta del sistema de establecimiento de implementación; y determinar si configurar o no un componente simulador de solicitudes del cliente.
El componente simulador de solicitudes del cliente 210A puede ser un componente simulador. En otras palabras, el componente simulador de solicitudes del cliente 210A puede no ser una implementación completa. El componente simulador de solicitudes del cliente 210A puede configurarse y/o alterarse para convertirse en una implementación. En algunas modalidades, el sistema de establecimiento de implementación 102 puede determinar si el componente simulador de solicitudes del cliente 210A responde correctamente a las llamadas de prueba de la API. Si el componente simulador de solicitudes del cliente 210A responde correctamente a llamadas de prueba de la API, en algunas modalidades, el sistema de establecimiento de implementación 102 puede certificar el componente simulador de solicitudes del cliente 210A, en donde el componente simulador de solicitudes del cliente 210A puede considerarse entonces una implementación.
La memoria 208 puede acoplarse al procesador 202 y puede almacenar datos, aplicaciones, claves y cualquier otra información adecuada. La memoria 208 puede tener la forma de uno o más dispositivos de memoria (por ejemplo, RAM, EEPR0M, chips de R0M), que use cualquier modo adecuado de almacenamiento de datos. En algunas modalidades, la memoria 208 en el primer procesador de solicitudes 108A también puede incluir un área de almacenamiento segura para almacenar datos sensibles tales como claves criptográficas.
La Figura 3 muestra un diagrama de bloques de un sistema de establecimiento de implementación 102 de acuerdo con una modalidad de la invención. El sistema de establecimiento de implementación 102 puede comprender una configuración de puerta de enlace 302 que comprende un módulo de simulación de API 302A, un módulo de generación de informes de prueba 302B y un portal 302C, un procesamiento de puerta de enlace 304 que incluye un generador de llamadas 304A y un analizador de respuestas 304B, así como también una persistencia de configuración de puerta de enlace 306 que incluye una configuración de modelo del método de solicitud 306A y una configuración de infra el
primer procesador de solicitudes 108A que incluye el componente simulador de solicitudes del cliente 210A. En algunas modalidades, el usuario 310 puede operar un ordenador, que no se muestra.
La configuración de puerta de enlace 302 puede acoplarse operativamente al procesamiento de puerta de enlace 304 y la persistencia de configuración de puerta de enlace 306. El procesamiento de puerta de enlace 304 puede acoplarse operativamente a la persistencia de configuración de puerta de enlace 306. El usuario 310 puede acceder a la configuración de puerta de enlace 302. El componente simulador de solicitudes del cliente 210A puede estar en comunicación operativa con el generador de llamadas 304A y el analizador de respuestas 304B.
La configuración de puerta de enlace 302 puede ser una puerta de enlace a través de la cual el usuario 310 del primer procesador de solicitudes 108A puede configurar detalles del procesador de solicitudes, tales como el modelo del método de solicitud y la infraestructura del procesador de solicitudes. La configuración de puerta de enlace 302 puede incluir el módulo de simulación de API 302A, el módulo generador de informes de pruebas 302B y el portal 302C. En algunas modalidades, la configuración de puerta de enlace 302 puede ser una interfaz a través de la cual el usuario 310 puede acceder al módulo de simulación de API 302A, al módulo generador de informes de pruebas 302B y al portal 302C. Por ejemplo, el usuario 310 puede acceder al módulo de simulación de API 302A a través de la configuración de puerta de enlace 302 para iniciar una simulación de API.
El procesamiento de la puerta de enlace 304 puede ser capaz de procesar datos. El procesamiento de la puerta de enlace 304 puede incluir un generador de llamadas 304A y un analizador de respuestas 304B. En algunas modalidades, el procesamiento de puerta de enlace puede incluir módulos capaces de procesar datos. En algunas modalidades, es posible que el usuario 310 no acceda al procesamiento de la puerta de enlace 304 y a los módulos que contiene.
La persistencia de configuración de puerta de enlace 306 puede acoplarse operativamente al procesamiento de la puerta de enlace 304 así como también al portal 302c . La persistencia de configuración de puerta de enlace 306 puede ser capaz de almacenar información y datos. En algunas modalidades, la persistencia de configuración de puerta de enlace 306 puede ser una memoria o base de datos, o un archivo en una memoria o base de datos. La persistencia de configuración de puerta de enlace 306 puede incluir una configuración del modelo del método de solicitud 306A y una configuración de infraestructura 306B.
El portal 302C puede ser un portal a través del cual el primer procesador de solicitudes 108A puede acceder a la persistencia de configuración de puerta de enlace 306. El portal 302C puede ser capaz de conectar al usuario 310 con la persistencia de configuración de puerta de enlace 306, que incluye la configuración del modelo del método de solicitud 306A y la configuración de infraestructura 306B. En algunas modalidades, el portal 302C puede permitir al usuario 310 ingresar el modelo del método de solicitud y la infraestructura del procesador de solicitudes.
La configuración del modelo del método de solicitud 306A puede almacenar el modelo del método de solicitud del primer procesador de solicitudes 108A. En algunas modalidades, la configuración del modelo del método de solicitud 306A puede configurarse para permitir al usuario 310 seleccionar los servicios de la API que admite el primer procesador de solicitudes 108A, la secuencia de servicios de la API que admite el procesador de solicitudes, los campos de la API que el procesador de solicitudes admite como obligatorios y los campos de API que el procesador de solicitudes admite como opcionales. Por ejemplo, el usuario 310 puede seleccionar el método de solicitud de una solicitud de atención sanitaria con los servicios de la API de "servicio de revisión de plan", "servicio de citas" y "servicio de estado". La configuración del modelo del método de solicitud 306A, puede entonces almacenar la selección del modelo del método de solicitud realizada por el usuario 310. En algunas modalidades, el portal 302C puede configurarse para permitir que el usuario 310 edite el modelo del método de solicitud y la infraestructura que se almacena en la configuración del modelo del método de solicitud 306A.
La configuración de infraestructura 306B puede almacenar la infraestructura del primer procesador de solicitudes 108A. En algunas modalidades, la infraestructura del primer procesador de solicitudes 108A puede ser los puntos de extremos del procesador de solicitudes y la dirección IP del procesador de solicitudes. En algunas modalidades, la configuración de infraestructura 306B puede almacenar otros datos de infraestructura relevantes tales como información que identifica el primer procesador de solicitudes 108A. Por ejemplo, la configuración de infraestructura 306B puede almacenar la dirección IP y los puntos de extremos del procesador de solicitudes, así como también el nombre de la entidad que opera el primer procesador de solicitudes 108A. En algunas modalidades, el primer procesador de solicitudes 108A puede asociarse con un identificador del procesador de solicitudes, que puede almacenarse en la configuración de infraestructura 306B.
El módulo de simulación de API 302A puede ser un módulo que cuando se ejecuta mediante un procesador es capaz de simular una API. En algunas modalidades el módulo de simulación de API 302A puede recibir el modelo del método de solicitud y una plant ce
302. La plantilla puede ser un conjunto de escenarios de prueba para que el sistema de establecimiento de implementación 102 genere llamadas de prueba a la API. El primer procesador de solicitudes 108A puede ser capaz de crear y/o usar una plantilla para probar el componente simulador de solicitudes del cliente 210A. Por ejemplo, la plantilla puede incluir un primer escenario de prueba en el que la llamada de prueba a la API se formatea con los campos correctos, un segundo escenario de prueba en el que la llamada de prueba a la API se formatea sin el campo obligatorio "importe", un tercer escenario de prueba en el que la llamada de prueba a la API se formatea con un código de moneda no compatible, y un cuarto escenario de prueba en el que la llamada de prueba a la API se formatea con un importe de reemboIso superior al importe de pago original.
El módulo de simulación de API 302A junto con un procesador puede invocar al generador de llamadas 304A para generar al menos una llamada de prueba a la API. En algunas modalidades, el módulo de simulación de API 302A puede ser capaz de generar el componente simulador de solicitudes del cliente 210A en respuesta a recibir un primer mensaje que incluye el modelo del método de solicitud y la plantilla, desde el primer procesador de solicitudes 108A.
En algunas modalidades, el módulo de simulación de API 302A junto con un procesador puede generar el componente simulador de solicitudes del cliente 210A en función al modelo del método de solicitud. En algunas modalidades, el módulo de simulación de API 302A puede generar el componente simulador de solicitudes del cliente 210A de manera que el componente simulador de solicitudes del cliente 210A sea capaz de responder a las llamadas de prueba a la API y llamadas a las API relacionadas con el modelo del método de solicitud. Por ejemplo, el módulo de simulación de API 302A puede generar el componente simulador de solicitudes del cliente 210A que puede ser capaz de responder llamadas a la a Pi de pago, mediante el uso de la especificación de la API de pago relevante de la plataforma de formato de solicitudes 106. En algunas modalidades, el módulo de simulación de API 302A puede compilar funciones y/o códigos establecidos por la API de procesamiento de solicitudes común.
En otras modalidades, el sistema de establecimiento de implementación 102 puede ser capaz de generar el módulo de simulación de API 302A. El sistema de establecimiento de implementación 102 puede recibir un mensaje de solicitud desde el primer procesador de solicitudes 108A, en donde el mensaje de solicitud indica una solicitud para generar un módulo de simulación. El sistema de establecimiento de implementación 102 puede generar un módulo de simulación de API 302A para cada procesador de solicitudes. Por ejemplo, puede haber cuatro procesadores de solicitudes que solicitan la generación de un simulador de API. El sistema de establecimiento de implementación 102 puede generar cuatro módulos de simulación de API para los cuatro procesadores de solicitudes.
En algunas modalidades, la generación del módulo de simulación de API 302A puede incluir que el sistema de establecimiento de implementación 102 compile funciones predefinidas, rutinas, estructuras de datos, clases de objetos, variables y/o llamadas remotas de acuerdo con la especificación de la API de procesamiento de solicitudes común. En otras modalidades, la generación del módulo de simulación de API 302a puede estar en función del modelo del método de solicitud. Por ejemplo, si el modelo del método de solicitud se refiere a una transferencia bancaria, entonces el módulo de simulación de API 302A puede incluir funciones y código predefinido relacionado con una transferencia bancaria.
El generador de llamadas 304A puede ser capaz de generar al menos una llamada de prueba a la API. La al menos una llamada de prueba a la API puede relacionarse con el modelo del método de solicitud del primer procesador de solicitudes 108A. El generador de llamadas 304A puede invocarse mediante el módulo de simulación de API 302A. El generador de llamadas 304A puede formatear la al menos una llamada de prueba a la API en función a la API de procesamiento de solicitudes común. El generador de llamadas 304A puede transmitir al menos una llamada de prueba a la API al componente simulador de solicitudes del cliente 210A del primer procesador de solicitudes 108A.
En algunas modalidades, si el generador de llamadas 304A recibe la plantilla desde el módulo de simulación de API 302A, el generador de llamadas 304A puede generar al menos una llamada de prueba a la API en función de la plantilla. Por ejemplo, la plantilla puede incluir un primer escenario de prueba en el que la llamada de prueba a la API se formatea con los campos correctos, un segundo escenario de prueba en el que la llamada de prueba a la API se formatea sin el campo obligatorio "doctor_name", y un tercer escenario de prueba en el que la llamada de prueba a la API se formatea sin los campos obligatorios "condición" and "fecha". En este ejemplo, el generador de llamadas 304A puede generar una primera llamada de prueba a la API que incluye campos con el formato correcto, una segunda llamada de prueba a la API que incluye un campo "doctor_name" faltante y una tercera llamada de prueba a la API que incluye un campo "condición" faltante y un campo "fecha" faltante.
En algunas modalidades, el generador de llamadas 304A puede generar al menos una respuesta esperada. La al menos una respuesta esperada puede ser una respuesta que el sistema de establecimiento de implementación 102 espera recibir. La al menos una respuesta esperada puede formatearse en función de la API de procesamiento de solicitudes comú el
campo obligatorio "doctor_name", la respuesta esperada puede incluir un campo de "error" con subcampos de "reason" y "ubicación". En este ejemplo, el subcampo "motivo" puede contener "se requiere el nombre del médico" y el subcampo "ubicación" puede contener "doctor_name".
El primer procesador de solicitudes 108A puede incluir un componente simulador de solicitudes del cliente 210a . El componente simulador de solicitudes del cliente 210A puede estar en comunicación operativa con el sistema de establecimiento de implementación 102. En algunas modalidades, el componente simulador de solicitudes del cliente 210A puede estar en comunicación operativa con el generador de llamadas 304A y el analizador de respuestas 304B. El componente simulador de solicitudes del cliente 210A puede ser un componente simulador que puede ser un marcador de posición para la implementación del procesador de solicitudes. Por ejemplo, el componente simulador de solicitudes del cliente 210A puede ser una implementación incompleta que puede necesitar completarse o puede necesitar certificarse mediante el sistema de establecimiento de implementación 102.
El componente simulador de solicitudes del cliente 210A puede ser capaz de generar al menos una respuesta en función de la al menos una llamada de prueba a la API. El componente simulador de solicitudes del cliente 210A puede ser capaz de transmitir la al menos una respuesta al sistema de establecimiento de implementación 102. En algunas modalidades, si el componente simulador de solicitudes del cliente 210A recibe cuatro llamadas de prueba a la API, el componente simulador de solicitudes del cliente 210A puede generar cuatro respuestas. El componente simulador de solicitudes del cliente 210A puede generar cualquier número adecuado de respuestas.
El analizador de respuestas 304B puede ser capaz de recibir al menos una respuesta del componente simulador de solicitudes del cliente 210A. El analizador de respuestas 304B puede analizar la al menos una respuesta. En algunas modalidades, el analizador de respuestas 304B puede recibir la al menos una respuesta y luego puede registrar la al menos una respuesta en una memoria o base de datos. En algunas modalidades, la al menos una respuesta puede registrarse en la persistencia de configuración de puerta de enlace 306. En otras modalidades, el analizador de respuestas 304B puede interpretar y analizar la al menos una respuesta, en donde la interpretación y análisis de la al menos una respuesta puede incluir el análisis de los campos de la al menos una respuesta y determinar si la al menos una respuesta coincide con la al menos una respuesta esperada. En algunas modalidades, el analizador de respuestas 304B puede transmitir la respuesta interpretada y analizada al módulo de generación de informes de prueba 302B. Por ejemplo, la al menos una respuesta puede ser una cadena de datos. La cadena de datos puede analizarse para obtener campos, tales como "doctor_name", "error", "ubicación", etc. La cadena de datos interpretada, es decir, los campos y subcampos, puede compararse con los campos y subcampos esperados.
El módulo de generación de informes de prueba 302B puede generar una notificación de respuesta. En algunas modalidades, el módulo de generación de informes de pruebas 302B puede recibir una respuesta analizada e interpretada desde el analizador de respuestas 304B, en donde el módulo de generación de informes de pruebas 302B puede generar la notificación de respuesta en función de la respuesta analizada e interpretada.
En algunas modalidades, la respuesta analizada e interpretada puede indicar diferencias entre la respuesta y la respuesta esperada. Por ejemplo, puede haber subcampos correspondientes a cada campo que indiquen si el campo coincide con el campo esperado correspondiente.
En algunas modalidades, el módulo de generación de informes de pruebas 302B puede generar la notificación de respuesta en función de la al menos una respuesta a al menos una llamada de prueba a la API. La notificación de respuesta puede incluir un indicador de éxito, un motivo y una lista de diferencias. El indicador de éxito puede indicar si la respuesta falló o si la respuesta tuvo éxito. El motivo puede describir por qué la respuesta falló o tuvo éxito. La lista de diferencias puede enumerar las diferencias entre la respuesta y la respuesta esperada.
El usuario 310 puede ser un usuario que se asocia con el primer procesador de solicitudes 108A. El usuario 310 puede acceder a la configuración de puerta de enlace 302.
En otras modalidades, el sistema de establecimiento de implementación 102 puede incluir además un procesador, una interfaz de red, elementos de entrada/salida y un medio legible por ordenador. Por ejemplo, el medio legible por ordenador del sistema de establecimiento de implementación 102 puede comprender código, que cuando se ejecuta mediante el procesador de datos del sistema de establecimiento de implementación 102 puede implementar un método que comprende: recibir un primer mensaje que incluye un modelo del método de solicitud y una plantilla de un procesador de solicitudes; generar al menos una llamada de prueba a la API en función del modelo del método de solicitud y la plantilla; transmitir la al menos una llamada de prueba a la API al procesador de solicitudes; recibir al menos una respuesta en función de la al menos una llamada de prueba a la API del procesador de solicitudes; evaluar la al menos una respuesta; generar u y
transmitir la notificación de respuesta al procesador de solicitudes.
B. Métodos
La Figura 4 muestra un diagrama de flujo que ilustra un método para establecer solicitudes para un procesador de solicitudes de acuerdo con una modalidad de la invención. El método que se ilustra en la Figura 4 se describirá en el contexto de un modelo del método de solicitud de una transferencia bancaria. Sin embargo, se entiende que la invención puede aplicarse a otras circunstancias (por ejemplo, pagos, atención sanitaria, servicios bancarios, comercio minorista, envíos, servicios públicos, gestión de datos, educación, fabricación, etc.). Aunque las etapas se ilustran en un orden específico, se entiende que las modalidades de la invención pueden incluir métodos que tienen las etapas en diferentes órdenes. Además, las etapas pueden omitirse o añadirse y aún pueden estar dentro de las modalidades de la invención.
En la etapa S402, el primer procesador de solicitudes 108A puede transmitir un mensaje de solicitud al sistema de establecimiento de implementación 102. El mensaje de solicitud puede incluir una solicitud para configurar un componente simulador de solicitudes del cliente 21 0A. En algunas modalidades, el mensaje de solicitud puede incluir el modelo del método de solicitud y la infraestructura del primer procesador de solicitudes 108A. La infraestructura del primer procesador de solicitudes 108A puede incluir los puntos de extremo, la dirección IP del procesador de solicitudes, el identificador del procesador de solicitudes y cualquier otra información adecuada. El modelo del método de solicitud puede almacenarse en la configuración del modelo del método de solicitud 306A. La infraestructura del primer procesador de solicitudes 108A puede almacenarse en la configuración de infraestructura 306B.
En otras modalidades, el usuario 310 del primer procesador de solicitudes 108A puede ingresar los detalles del modelo del método de solicitud y la infraestructura del primer procesador de solicitudes 108A en la persistencia de configuración de puerta de enlace 306, a través del portal 302C.
En algunas modalidades, el primer procesador de solicitudes 108A puede ser capaz de definir el modelo del método de solicitud, tal como, por ejemplo, qué servicios de la API usar, qué campos de la API usar para la solicitud y qué casos de uso admitir. Algunos ejemplos de servicios de la API podrían ser "servicio de la API de venta para procesamiento de pagos", "servicio de reemboIso" y "servicio de estado". Cada servicio de la API a usar puede usar diferentes campos de la API. Por ejemplo, el servicio de la API "servicio de la API de venta para procesamiento de pagos" puede admitir los campos de "importe," "moneda," "nombre del cliente," "descripción del comerciante," "país" e "ID de transacción". El primer procesador de solicitudes 108A puede definir las características que se usarán con los servicios de la API. Por ejemplo, el "servicio de reemboIso" del servicio de la API puede usar la función de "se admiten reemboIsos parciales", mientras que el "servicio de estado" del servicio de la API puede usar la función de "puede usarse para obtener el estado de un pago o un reemboIso".
En la etapa S404, el sistema de establecimiento de implementación 102 puede generar el módulo de simulación de API 302A. El módulo de simulación de API 302A puede generarse de manera que pueda acceder el procesador de solicitudes que transmitió el mensaje de solicitud. En algunas modalidades, el módulo de simulación de API 302A puede asociarse con el primer procesador de solicitudes 108A que transmitió el mensaje de solicitud. En otras modalidades, puede haber varios módulos de simulación de API diferentes, en donde cada módulo de simulación de API diferente puede asociarse a un procesador de solicitudes diferente. Por ejemplo, el primer procesador de solicitudes 108A puede acceder a un primer módulo de simulación de API, mientras que el segundo procesador de solicitudes 108B puede acceder a un segundo módulo de simulación de API.
En algunas modalidades, la generación del módulo de simulación de API 302A puede incluir el sistema de establecimiento de implementación 102 que compila funciones predefinidas, rutinas, estructuras de datos, clases de objetos, variables y/o llamadas remotas de acuerdo con la especificación de la API de procesamiento de solicitudes común y el modelo del método de solicitud. Por ejemplo, si el modelo del método de solicitud se refiere a una transferencia bancaria, entonces el módulo de simulación de API 302A puede incluir funciones y código predefinido relacionado con una transferencia bancaria.
En la etapa S406, después de recibir el mensaje de solicitud, el sistema de establecimiento de implementación 102 puede generar el componente simulador de solicitudes del cliente 210A. El sistema de establecimiento de implementación 102 puede generar el componente simulador de solicitudes del cliente 210A en función del modelo del método de solicitud. Por ejemplo, el modelo del método de solicitud puede ser una transferencia bancaria. El componente simulador de solicitudes del cliente 210A puede generarse de manera que pueda responder a las llamadas de prueba a la API y las llamadas a la API que se relacionan con una transferencia bancaria. Por ejemplo, el sistema de establecimiento de implementación 102 puede recuperar funciones predefinidas relacionadas con una transferencia bancaria y compilarlas en un componente simulador de solicitudes del cliente 210A.
En la etapa S408, después de generar el componente simulador de solicitudes del cliente 210A y el módulo de simulación de API 302A, el sistema de establecimiento de implementación 102 puede transmitir el componente simulador de solicitudes del cliente 210A al primer procesador de solicitudes 108A.
En algunas modalidades, el primer procesador de solicitudes 108A puede generar el componente simulador de solicitudes del cliente 210A en lugar de que el sistema de establecimiento de implementación 102 genere el componente simulador de solicitudes del cliente 21 0A. Por ejemplo, el usuario 310 puede elegir que el primer procesador de solicitudes 108A genere el componente simulador de solicitudes del cliente 210A.
En la etapa S410, el primer procesador de solicitudes 108A puede configurar el componente simulador de solicitudes del cliente 21 0A. En algunas modalidades, el primer procesador de solicitudes 108A puede configurar el componente simulador de solicitudes del cliente 210A con los puntos de extremo, certificaciones y el identificador del sistema de solicitudes. El componente simulador de solicitudes del cliente 210A puede configurarse para interactuar con el primer procesador de solicitudes 108A. Por ejemplo, el primer procesador de solicitudes 108A puede configurar un canal de comunicación entre el sistema de establecimiento de implementación 102 y el componente simulador de solicitudes del cliente 210A mediante el uso de los puntos de extremo.
En la etapa S412, el primer procesador de solicitudes 108A puede invocar el módulo de simulación de API en el sistema de establecimiento de implementación 102. En algunas modalidades, el primer procesador de solicitudes 108A puede transmitir un primer mensaje que incluye el modelo del método de solicitud y la plantilla al sistema de establecimiento de implementación 102. La plantilla puede ser un conjunto de escenarios de prueba para que el sistema de establecimiento de implementación 102 genere llamadas de prueba a la API. El primer procesador de solicitudes 108A puede ser capaz de crear y/o usar una plantilla para probar el componente simulador de solicitudes del cliente 210A. Por ejemplo, la plantilla puede incluir un primer escenario de prueba en el que la llamada de prueba a la API se formatea con los campos correctos, un segundo escenario de prueba en el que la llamada de prueba a la API se formatea sin el campo obligatorio "importe", un tercer escenario de prueba en el que la llamada de prueba a la API se formatea con un código de moneda no compatible, y un cuarto escenario de prueba en el que la llamada de prueba a la API se formatea con un importe de reemboIso superior al importe de pago original.
En la etapa S414, después de recibir el primer mensaje, el sistema de establecimiento de implementación 102 puede generar al menos una llamada de prueba a la API mediante el uso del generador de llamadas 304A. La al menos una llamada de prueba a la API puede generarse en función del modelo del método de solicitud y la plantilla. En algunas modalidades, el generador de llamadas 304A puede recibir el modelo del método de solicitud desde la persistencia de configuración de puerta de enlace 306 a través del procesamiento de la puerta de enlace 304. La al menos una llamada de prueba a la API puede incluir campos conforme lo solicite el modelo del método de solicitud. El sistema de establecimiento de implementación 102 puede generar la al menos una llamada de prueba a la API como se describió anteriormente y no necesita repetirse aquí. En algunas modalidades, el sistema de establecimiento de implementación 102 puede generar al menos una respuesta esperada. Una respuesta esperada puede ser una respuesta que el sistema de establecimiento de implementación 102 espera recibir. La al menos una respuesta esperada puede formatearse en función de la API de procesamiento de solicitudes común. En algunas modalidades, puede haber el mismo número de llamadas de prueba a la API y respuestas esperadas.
En la etapa S416, el sistema de establecimiento de implementación 102 puede transmitir la al menos una llamada de prueba a la API al componente simulador de solicitudes del cliente 210A en el primer procesador de solicitudes 108A. En la etapa S418, después de recibir la llamada de prueba a la API, el primer procesador de solicitudes 108A puede generar al menos una respuesta a la llamada de prueba a la API. La al menos una respuesta puede ser en función de la al menos una llamada de prueba a la API y puede incluir información relacionada con el tipo de modelo del método de solicitud y plantilla usada. Por ejemplo, al menos una respuesta puede incluir campos para "status", "responseCode", "processorResponse", y "errorMessage". Los campos pueden incluir subcampos. Por ejemplo, el campo "processorResponse" puede incluir los subcampos de "paymentRedirectURL" y "error". Además, los subcampos pueden incluir subcampos. Por ejemplo, el subcampo "paymentRedirectURL" puede incluir los subcampos "type" y "descripción". 0tro ejemplo, el subcampo "error" puede incluir los subcampos "location," "reason," y "message". La al menos una respuesta puede generarse en un formato conforme a la API de procesamiento de solicitudes común. Pueden usarse todos los campos y subcampos adecuados.
En algunas modalidades, la al menos una llamada de prueba a la API puede ser más de una llamada a la API. Por ejemplo, la al menos una llamada de prueba a la API pueden ser tres llamadas a la API. La primera llamada de prueba a la API puede relacionarse con el servicio de la API "servicio de venta para procesamiento de pagos", la segunda llamada de prueba a la API puede relacionarse con el servicio de la API "servicio de reemboIso" y la tercera llamada de prueba a la API puede relacionarse con el servicio de la API "servicio de estado". Las llamadas de prueba a la API pueden tener en una secuencia particular cuando se envían
Por ejemplo, la llamada a la API de prueba puede ser:
"SaleApiRequest": {
"billTo": {
customerName: "Rohit"
país: NL },
"purchaseTotal": {
moneda: EUR
},
"merchantDescriptor": {
Descripción: "Comercio grande"
},
"paymentDetails": {
txnID: ABCD1234 }, }
Una respuesta de ejemplo para la llamada de prueba a la API mencionada anteriormente podría ser:
"estado": "FALL0",
"responseCode": "10000",
"processorResponse": {
"error": [ {
"ubicación": " importe",
"motivo": "faltante",
"mensaje": "Debe enviar importe"
}, ]
"errorMessage": "string" ("El importe es obligatorio")
}
En el ejemplo anterior, la llamada de prueba a la API se transmitió sin un campo de "importe". En algunas modalidades, la llamada de prueba a la API puede generarse y transmitirse sin todos los campos obligatorios. Esto puede hacerse para probar si el componente simulador de solicitudes del cliente 210A del primer procesador de solicitudes 108A puede generar la respuesta esperada a una llamada a la API con un campo faltante. En el ejemplo anterior, la respuesta indica un "estado" de "FALLID0", una "ubicación" de "importe" y un "motivo" de "faltante".
En otro ejemplo, la llamada de prueba a la API puede incluir un código de moneda no compatible. Por ejemplo, el primer procesador de solicitudes 108A puede operarse por un comercio en Europa. El comerciante solo puede aceptar euros como moneda. En este ejemplo, el modelo del método de solicitud puede admitir un campo de "purchaseTotal" con un subcampo de "moneda", en donde el subcampo de "moneda" debe ser EUR. A continuación, se muestra un ejemplo de llamada de prueba a la API con el subcampo "moneda" establecido en USD:
"SaleApiRequest": {
"billTo": {
customerName: "Rohit"
país: NL
},
"purchaseTotal": {
Importe: 10
moneda: USD
},
"merchantDescriptor": {
Descripción: "Comercio grande" },
"paymentDetails": {
txnID: ABCD1234
},
}
Dado que la llamada de prueba a la API incluyó un código de moneda no admitido, la respuesta esperada sería:
"estado": "FALL0",
"responseCode": "10000",
"processorResponse": {
"error": [ {
"ubicación": "moneda",
"motivo": "no válido",
"mensaje": "Solo se admite el EUR como moneda"
},]
"errorMessage": "string" ("Solo se admiten euros como moneda")
}
En este ejemplo, la respuesta esperada incluye un "estado" de "fallido". La respuesta esperada indica que el subcampo "moneda" en la llamada de prueba a la API es no válido porque solo se admite EUR como moneda.
En otro ejemplo, pueden enviarse dos llamadas de prueba a la API desde el sistema de establecimiento de implementación 102 al primer procesador de solicitudes 108A. La primera llamada de prueba a la API puede ser para una compra y puede incluir un total de compra de 10 EUR. La segunda llamada de prueba a la API, a continuación, puede ser para un reemboIso de la compra anterior. La segunda llamada de prueba a la API puede enviarse con un reemboIso total de 20 EUR. A continuación, la respuesta esperada, puede incluir un error y puede indicar que el importe del reemboIso es mayor que el importe original. El ejemplo de llamada a la API de prueba:
"RefundApiRequest": {
"purchaseTotal": {
Importe: 20
moneda: EUR
},
"merchantDescriptor": {
Descripción: "Comercio Grande" },
"paymentDetails": {
txnID: ABCD1234
},
}
Un ejemplo de respuesta esperada:
"estado": "FALL0",
"responseCode": "10000",
"processorResponse": {
"error": [
{
"ubicación": "moneda",
"motivo": "no válido",
"mensaje": "El importe del reemboIso es superior al importe del pago original"
},
]
"errorMessage": "string" ("El importe del reemboIso es superior al importe del pago original") }
En otro ejemplo, la llamada de prueba a la API puede incluir campos obligatorios, en función del modelo del método de solicitud. La siguiente llamada de prueba a la API puede transmitirse desde el sistema de establecimiento de implementación 102 hasta el primer procesador de solicitudes 108A. A continuación, la respuesta esperada indica la creación exitosa de una URL de redirección de pago.
"SaleApiRequest": {
"billTo": {
customerName: "Rohit"
país: NL
},
"purchaseTotal": {
Importe: 10
moneda: EUR
},
"merchantDescriptor": {
Descripción: "Comercio grande"
},
"paymentDetails": {
txnID: ABCD1234 }
Un ejemplo de respuesta esperada:
"SaleAPIResponse" : {
"estado": "ÉXIT0",
"responseCode": "10000",
"processorResponse": {
"paymentRedirectURL": [
{
"tipo": "https://xyzbank.com/tthis784uhjrjhhujshd854j"
"descripción": "URL creada con éxito",
},
}
En este ejemplo, dado que la llamada de prueba a la API incluye todos los campos obligatorios en el formato correcto, la respuesta esperada es la creación de una URL de redirección de pago.
En la etapa S420, después de generar la al menos una respuesta, el primer procesador de solicitudes 108A puede transmitir la al menos una respuesta al sistema de establecimiento de implementación 102. En la etapa S422, después de recibir la al menos una respuesta, el sistema de establecimiento de implementación 102 puede verificar la al menos una respuesta. En algunas modalidades, verificar la al menos una respuesta puede incluir comparar la al menos una respuesta con la al menos una respuesta esperada. El sistema de establecimiento de implementación 102 puede determinar si los subcampos específicos de la respuesta coinciden con los respectivos subcampos de la respuesta esperada. Por ejemplo, al menos una respuesta puede incluir un subcampo de "merchantDescriptor" establecido en "Comerciante A". Sin embargo, la respuesta esperada puede incluir un subcampo de "merchantDescriptor" establecido en "Comerciante B". En este caso, la respuesta es diferente a la respuesta esperada, por lo tanto, el sistema de establecimiento de implementación 102 puede determinar que la al menos una llamada de prueba a la API y la al menos una respuesta no coinciden.
En la etapa S424, el sistema de establecimiento de implementación 102 puede generar una notificación de respuesta en función de la al menos una respuesta a la al menos una llamada de prueba a la API. La notificación de respuesta puede incluir un indicador de éxito, un motivo y una lista de diferencias. El indicador de éxito puede indicar si la respuesta falló o si la respuesta tuvo éxito. El motivo puede describir por qué la respuesta falló o tuvo éxito. La lista de diferencias puede enumerar las diferencias entre la respuesta y la respuesta esperada.
La notificación de respuesta puede referirse a más de una llamada de prueba a la API. Por ejemplo, si se transmitieron tres llamadas de prueba al API desde el sistema de establecimiento de implementación 102 al primer procesador de solicitudes 108A, y se transmitieron tres respuestas desde el primer procesador de solicitudes 108A al sistema de establecimiento de implementación 102, entonces la notificación de respuesta puede incluir tres indicadores de éxito, tres motivos y tres listas de diferencias.
En algunas modalidades, el motivo puede ser que el mensaje de respuesta de la prueba se formateó incorrectamente. Por ejemplo, el primer procesador de solicitudes 108A puede haber respondido con un campo o subcampo incorrecto. 0tro motivo puede ser que hubo un fallo de comunicación entre el primer procesador de solicitudes 108A y el sistema de establecimiento de implementación 102. Por ejemplo, puede haber un corte de red que haga que el sistema de establecimiento de implementación 102 no reciba la respuesta. En este caso, puede haber un tiempo predeterminado antes de que el sistema de establecimiento de implementación 102 indique que la respuesta ha fallado. El tiempo predeterminado puede ser cualquier cantidad de tiempo adecuada (por ejemplo, 30 minutos, 4 horas, 1 día, etc.). En algunas modalidades, otros motivos pueden relacionarse con los campos, subcampos, contenido y formato. En otras modalidades, si el indicador de éxito indica que la respuesta tuvo éxito, entonces el motivo puede ser "respuesta correctamente formateada" u otro mensaje adecuado.
En la etapa S426, el sistema de establecimiento de implementación 102 puede transmitir la notificación de respuesta al primer procesador de solicitudes 108A. En la etapa S428, después de recibir la notificación de respuesta, el primer procesador de solicitudes 108A puede determinar si configurar o no el componente simulador de solicitudes del cliente 210A en función de la notificación de respuesta. En algunas modalidades, el primer procesador de solicitudes 108A puede configurar el componente simulador de solicitudes del cliente 210A si la al menos una respuesta no coincide con la al menos una respuesta esperada. El componente simulador de solicitudes del cliente 210A puede configurarse de manera que formatee correctamente las respuestas de acuerdo con la API de procesamiento de solicitudes común. Por ejemplo, si la notificación de respuesta indica que el subcampo de "tipo" en la respuesta es diferente del subcampo de "tipo" en la respuesta esperada, entonces el primer procesador de solicitudes 108A puede configurar el componente simulador de solicitudes del cliente 210A para alterar la forma en que se genera el subcampo de "tipo".
En algunas modalidades, si el indicador de éxito de la notificación de respuesta indica que la respuesta falló, entonces el primer procesador de solicitudes 108A puede repetir las etapas anteriores, al comenzar en la etapa S412. El primer procesador de solicitudes 108A puede repetir las etapas hasta que el indicador de éxito indique que la respuesta tuvo éxito.
En algunas modalidades, si el indicador de éxito indica que la respuesta tuvo éxito, el primer procesador de solicitudes 108A puede determinar que no es necesario configurar el componente simulador de solicitudes del cliente 210A. El primer procesador de solicitudes 108A puede entonces transmitir una solicitud de certificación al sistema de establecimiento de implementación 102. En algunas modalidades, la solicitud de certificación puede incluir una solicitud para que el componente simulador de solicitudes del cliente del procesador de solicitudes se certifique mediante el sistema de establecimiento de implementación 102. El sistema de establecimiento de implementación 102 puede evaluar la solicitud de certificación y certificar el procesador de solicitudes dentro de un marco de tiempo predeterminado. En algunas modalidades, el sistema de establecimiento de implementación 102 puede determinar certificar el componente simulador de solicitudes del procesador de solicitudes. En otras modalidades, el sistema de establecimiento de implementación 102 puede determinar no certificar el componente simulador de solicitudes del cliente del procesador de solicitudes.
En algunas modalidades, si el componente simulador de solicitudes del procesador de solicitudes se certifica, el componente simulador de solicitudes se considerará como una implementación, y el primer procesador de solicitudes 108A puede recibir solicitudes desde el sistema de solicitudes 104 a través de la plataforma de formato de solicitudes 106.
La Figura 5 muestra un diagrama de flujo que ilustra un método alternativo para establecer solicitudes para un procesador de solicitudes de acuerdo con una modalidad de la invención. El método que se ilustra en la Figura 5 se describirá en el contexto de un modelo del método de solicitud de una solicitud de atención sanitaria. Sin embargo, se entiende que la invención puede aplicarse a otras circunstancias (por ejemplo, pagos, atención sanitaria, servicios bancarios, comercio minorista, envíos, servicios públicos, gestión de datos, educación, fabricación, etc.). Aunque las etapas se ilustran en un orden específico, se entiende que las modalidades de la invención pueden incluir métodos que tienen las etapas en diferentes órdenes. Además, las etapas pueden omitirse o añadirse y aún pueden estar dentro de las modalidades de la invención. Las especificaciones sobre cómo se genera el componente simulador de solicitudes del cliente 210A, cómo se transmiten los mensajes y otros detalles se han descrito anteriormente y no es necesario repetirlos aquí.
En algunas modalidades, el primer procesador de solicitudes 108A puede ser un ordenador servidor que se asocia con un profesional de servicios sanitarios. El primer procesador de solicitudes 108A puede querer recibir llamadas de la API desde los sistemas de solicitudes.
En la etapa S502, el primer procesador de solicitudes 108A puede transmitir un mensaje de solicitud al sistema de establecimiento de implementación 102. El mensaje de solicitud puede incluir una solicitud para generar un módulo de simulación de API y un modelo del método de solicitud. Al recibir el mensaje de solicitud, en la etapa S504, el sistema de establecimiento de implementación 102 puede generar el módulo de simulación de API. En la etapa S506, el primer procesador de solicitudes 108A puede generar un componente simulador de solicitudes del cliente 210A. En algunas modalidades, la etapa S504 y la etapa S506 pueden ocurrir simultáneamente o en momentos similares. En otras modalidades, después de generar el módulo de simulación de API, el sistema de establecimiento de implementación 102 puede transmitir un mensaje al primer procesador de solicitudes 108A que indique que el módulo de simulación de API se ha generado.
En la etapa S508, el primer procesador de solicitudes 108A puede transmitir un primer mensaje que incluye un modelo del método de solicitud y una plantilla al sistema de establecimiento de implementación 102. Por ejemplo, el modelo del método de solicitud puede estar relacionado con una solicitud de atención sanitaria. La plantilla, en este ejemplo, puede incluir un primer escenario de prueba en el que la llamada de prueba a la API se formatea con los campos correctos, un segundo escenario de prueba en el que la llamada de prueba a la API se formatea sin un campo obligatorio "fecha" y un tercer escenario de prueba en el que la llamada de prueba a la API se formatea con un número de licencia de médico no válido.
En la etapa S510, el sistema de establecimiento de implementación 102 puede generar al menos una llamada de prueba a la API en función del modelo del método de solicitud y la plantilla. Por ejemplo, el sistema de establecimiento de implementación 102 puede generar tres llamadas de prueba a la API ya que la plantilla incluye tres escenarios de prueba. Una primera llamada de prueba a la API puede incluir campos correctos, una segunda llamada de prueba a la API puede no incluir un campo obligatorio "fecha" y una tercera llamada de prueba a la API puede incluir un número de licencia de médico inválido.
En la etapa S512, el sistema de establecimiento de implementación 102 puede transmitir la al menos una llamada de prueba a la API al primer procesador de solicitudes 108A. En la etapa S514, después de recibir al menos una llamada de prueba a la API, el primer procesador de solicitudes 108A puede generar al menos una respuesta en base de la al menos una llamada de prueba a la API. En este ejemplo, dado que la al menos una llamada de prueba a la API son tres llamadas de prueba a la API, el primer procesador de solicitudes 108A puede generar tres respuestas. Una primera respuesta puede no incluir un campo de error, una segunda respuesta puede incluir un campo de error establecido en "campo de fecha obligatorio" y una tercera respuesta puede incluir un campo de error establecido en "número de licencia de médico no válido" con un subcampo de ubicación establecido en "LicenseNumber".
En la etapa S516, el primer procesador de solicitudes 108A puede transmitir la al menos una respuesta al sistema de establecimiento de implementación 102. En la etapa S518, después de recibir la al menos una respuesta, el sistema de establecimiento de implementación 102 puede evaluar la al menos una respuesta. El sistema de establecimiento de implementación 102 puede haber generado previamente al menos una respuesta esperada. El sistema de establecimiento de implementación 102 puede comparar la al menos una respuesta con la al menos una respuesta esperada. Por ejemplo, el sistema de establecimiento de implementación 102 puede haber generado previamente tres respuestas esperadas, ya que el sistema de establecimiento de implementación 102 generó tres llamadas de prueba a la API. Una primera respuesta esperada puede no incluir un campo de error, una segunda respuesta esperada puede incluir un campo de error establecido como "campo de fecha obligatorio", y una tercera respuesta esperada puede incluir un campo de error establecido como "número de licencia de médico no válido" con un subcampo de ubicación establecido en "LicenseNumber". En este ejemplo, las tres respuestas coinciden con las tres respuestas esperadas, respectivamente.
En la etapa S520, el sistema de establecimiento de implementación 102 puede generar una notificación de respuesta en función de la al menos una respuesta. En este ejemplo, la notificación de respuesta puede indicar que todas las llamadas de prueba a la API han tenido éxito.
En la etapa S522, el sistema de establecimiento de implementación 102 puede transmitir la notificación de respuesta al primer procesador de solicitudes 108A. En la etapa S524, después de recibir la notificación de respuesta, el primer procesador de solicitudes 108A puede determinar si la notificación de respuesta indica un éxito. En este ejemplo, el sistema de establecimiento de implementación 102 puede determinar que la notificación de respuesta indica un éxito.
En la etapa S526, después de determinar que la notificación de respuesta indica un éxito, el primer procesador de solicitudes 108A puede generar una solicitud de certificación. La solicitud de certificación puede incluir una solicitud para que el componente simulador de solicitudes del cliente se certifique mediante el sistema de establecimiento de implementación 102.
En la etapa S528, el primer procesador de solicitudes 108A puede transmitir la solicitud de certificación al sistema de establecimiento de implementación 102. En la etapa S530, después de recibir la solicitud de certificación, el sistema de establecimiento de implementación 102 puede determinar certificar el componente simulador de solicitudes del cliente 210A del primer procesador de solicitudes 108A. El sistema de establecimiento de implementación 102 puede determinar certificar el componente simulador de solicitudes del cliente 210A en función de varios criterios. Uno de los criterios puede ser si el componente simulador de solicitudes del cliente 210A generó previamente respuestas con el formato correcto. 0tro criterio puede ser en función de factores de riesgo. 0tros criterios pueden predeterminarse mediante el sistema de establecimiento de implementación 102. En la etapa S532, el sistema de establecimiento de implementación 102 puede transmitir una respuesta de certificación al primer procesador de solicitudes 108A. La respuesta de certificación puede indicar si el componente simulador de solicitudes del cliente 210A ha sido certificado o no.
Las modalidades de la invención proporcionan diversas ventajas. Una ventaja es que el procesador de solicitudes puede definir un modelo y una plantilla del método de solicitud para probar el componente simulador de solicitudes del cliente del procesador de solicitudes. Esto es ventajoso porque el procesador de solicitudes puede codificar conforme a la API de procesamiento de solicitudes común, pero puede no necesitar entradas adicionales desde la plataforma de formato de solicitudes como en métodos y sistemas anteriores. El procesador de solicitudes puede interactuar automáticamente con el sistema de establecimiento de implementación 102.
Además, las modalidades de la invención reducen el número de etapas para establecer una implementación en oposición a los métodos anteriores, que se describieron anteriormente. Por ejemplo, las modalidades de la invención permiten que el procesador de solicitudes reciba automáticamente llamadas a la API, responda a las llamadas a la API y reciba datos relacionados con las llamadas y respuestas a la API. En los métodos anteriores, los usuarios del procesador de solicitudes y la plataforma de formato de solicitudes necesitarían comunicarse entre sí, generalmente a través de correo electrónico, para configurar las llamadas a la API entre las máquinas. La reducción en el número de etapas permite que las modalidades de la invención sean más eficientes que los métodos anteriores.
0tra ventaja es que las modalidades de la invención permiten una certificación mucho más rápida de la implementación que los métodos anteriores. Esto se debe, al menos, a la reducción de las etapas que realizaría un ser humano. 0tra ventaja es que el tiempo entre la generación de una respuesta en el procesador de solicitudes y la recepción de la notificación de respuesta en el procesador de solicitudes se reduce significativamente en comparación con métodos y sistemas anteriores.
0tra ventaja es que el procesador de solicitudes puede solicitar la certificación inmediatamente después de establecer el componente simulador de solicitudes del cliente del procesador de solicitudes
Debe entenderse que cualquiera de las modalidades de la presente invención puede implementarse en forma de lógica de control mediante el uso de hardware (por ejemplo, un circuito integrado específico de la aplicación o una serie de compuertas programables en campo) y/o mediante el uso de programas informáticos con un procesador generalmente programable en una forma modular o integrada. Como se usa en la presente descripción, un procesador incluye un procesador de un solo núcleo, un procesador de múltiples núcleos en un mismo chip integrado o múltiples unidades de procesamiento en una sola placa de circuito o en red. En base a la descripción y las enseñanzas proporcionadas en la presente descripción, un experto en la técnica puede conocer y apreciar otras maneras y/o métodos para implementar las modalidades de la presente invención mediante el uso de hardware y una combinación de hardware y programas.
Cualquiera de los componentes o funciones de los programas que se describen en esta solicitud puede implementarse como código de programa para ejecutarse mediante un procesador que use cualquier lenguaje informático adecuado tal como, por ejemplo, Java, C, C++, C#, 0bjective-C, Swift o lenguaje de secuencias de comandos como Perl o Python que usan, por ejemplo, técnicas convencionales u orientadas a objetos. El código de programa puede almacenarse como una serie de instrucciones o comandos en un medio legible por ordenador para su almacenamiento y/o transmisión. Los medios adecuados incluyen memoria de acceso aleatorio (RAM), memoria de solo lectura (R0M), un medio magnético como un disco duro o un disquete, o un medio óptico tal como un disco compacto (CD) o DVD (disco versátil digital), memoria flash y similares. El medio legible por ordenador puede ser cualquier combinación de dichos dispositivos de almacenamiento o transmisión.
Estos programas también pueden codificarse y transmitirse mediante el uso de señales portadoras que se adaptan para la transmisión a través de redes cableadas, ópticas y/o inalámbricas que conforman una variedad de protocolos, incluyendo Internet. Como tal, puede crearse un medio legible por ordenador de acuerdo con una modalidad de la presente invención mediante el uso de una señal de datos codificada con dichos programas. Los medios legibles por ordenador codificados con el código de programa pueden empaquetarse con un dispositivo compatible o proporcionarse por separado de otros dispositivos (por ejemplo, mediante descarga de Internet). Cualquier medio legible por ordenador puede residir en o dentro de un solo producto informático (por ejemplo, un disco duro, un CD o un sistema informático completo) y puede estar presente en o dentro de diferentes productos informáticos dentro de un sistema o red. Un sistema informático puede incluir un monitor, una impresora u otra pantalla adecuada para proporcionar a un usuario cualquiera de los resultados mencionados en la presente descripción.
La descripción anterior es ilustrativa y no es restrictiva. Muchas variaciones de la invención resultarán evidentes para los expertos en la técnica tras la revisión de la descripción. Por lo tanto, el alcance de la invención no debe determinarse con referencia a la descripción anterior, sino que debe determinarse con referencia a las reivindicaciones pendientes junto con su alcance completo o equivalentes.
Una o más características de cualquier modalidad pueden combinarse con una o más características de cualquier otra modalidad sin apartarse del alcance de la invención.
Como se usa en la presente descripción, el uso de "un", "una" o "el/la/los/las" pretende decir "al menos uno", a menos que se indique específicamente lo contrario.
Claims (7)
1. Un método implementado por ordenador que comprende:
recibir (S402), mediante un sistema de establecimiento de implementación y desde un procesador de solicitudes, un mensaje de solicitud, en donde el mensaje de solicitud incluye un modelo del método de solicitud y una plantilla;
en respuesta a la recepción del mensaje de solicitud:
generar (S404), mediante el sistema de establecimiento de implementación, un módulo de simulación que se configura para simular una interfaz de programación de aplicaciones, API; y
generar (S406), mediante el módulo de simulación que se ha generado mediante el sistema de establecimiento de implementación, un componente simulador de solicitudes del cliente en función del modelo del método de solicitud, de manera que el componente simulador de solicitudes del cliente se configura para responder a las llamadas de prueba a la API y llamadas a la API relacionadas con el modelo del método de solicitud;
transmitir (S408), mediante el sistema de establecimiento de implementación, el componente simulador de solicitudes del cliente al procesador de solicitudes;
generar (S414), mediante el sistema de establecimiento de implementación, al menos una llamada de prueba a la API en función del modelo del método de solicitud y la plantilla;
transmitir (S416), mediante el sistema de establecimiento de implementación, la al menos una llamada de prueba a la API al componente simulador de solicitudes del cliente en el procesador de solicitudes; recibir (S420), mediante el sistema de establecimiento de implementación, al menos una respuesta en función de la al menos una llamada de prueba a la API desde el componente simulador de solicitudes del cliente al procesador de solicitudes;
evaluar (S422), mediante el sistema de establecimiento de implementación, la al menos una respuesta; generar (S424), mediante el sistema de establecimiento de implementación, una notificación de respuesta en función de la al menos una respuesta; y
transmitir (S426), mediante el sistema de establecimiento de implementación, la notificación de respuesta al procesador de solicitudes.
2. El método de la reivindicación 1, que comprende además:
recibir, mediante el sistema de establecimiento de implementación, una solicitud de certificación que incluye una solicitud para que el componente simulador de solicitudes del cliente se certifique mediante el sistema de establecimiento de implementación; y
certificar, mediante el sistema de establecimiento de implementación, el componente simulador de solicitudes del cliente en función de al menos la solicitud de certificación.
3. El método de la reivindicación 1 o 2, en donde evaluar, mediante el sistema de establecimiento de implementación, la al menos una respuesta comprende además:
generar, mediante el sistema de establecimiento de implementación, al menos una respuesta esperada en función del modelo del método de solicitud y la plantilla; y
comparar, mediante el sistema de establecimiento de implementación, la al menos una respuesta con la al menos una respuesta esperada.
4. El método de la reivindicación 3, en donde la al menos una llamada de prueba a la API, la al menos una respuesta y la al menos una respuesta esperada se formatean en función de una especificación de la API de una plataforma de formato de solicitudes asociada con el sistema de establecimiento de implementación.
5. El método de cualquiera de las reivindicaciones 1 a 4, en donde el modelo del método de solicitud y la plantilla se refieren a la gestión de datos.
6. El método de cualquiera de las reivindicaciones 1 a 5, en donde la notificación de respuesta incluye un indicador de éxito, un motivo y una lista de diferencias.
7. Un sistema de establecimiento de implementación (102) que comprende:
un procesador;
un dispositivo de memoria; y
un medio legible por ordenador que se acopla al procesador, el medio legible por ordenador comprende un código ejecutable mediante el procesador para implementar el método de cualquiera de las reivindicaciones 1 a 6.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/913,638 US10467066B2 (en) | 2018-03-06 | 2018-03-06 | System and method for establishing common request processing |
| PCT/US2019/020620 WO2019173245A1 (en) | 2018-03-06 | 2019-03-04 | System and method for establishing common request processing |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2951835T3 true ES2951835T3 (es) | 2023-10-25 |
Family
ID=67843907
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES19764336T Active ES2951835T3 (es) | 2018-03-06 | 2019-03-04 | Sistema y método para establecer el procesamiento de solicitudes común |
Country Status (6)
| Country | Link |
|---|---|
| US (2) | US10467066B2 (es) |
| EP (1) | EP3762882B1 (es) |
| CN (1) | CN111819589B (es) |
| ES (1) | ES2951835T3 (es) |
| SG (1) | SG11202008393TA (es) |
| WO (1) | WO2019173245A1 (es) |
Families Citing this family (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| BR112018070864A2 (pt) | 2016-05-03 | 2019-02-05 | Visa Int Service Ass | aparelho, método, e, computador servidor |
| US10430179B1 (en) * | 2019-03-07 | 2019-10-01 | Capital One Services, Llc | Methods and systems for managing application configurations |
| US10929276B2 (en) * | 2019-06-14 | 2021-02-23 | Paypal, Inc. | Simulation computing services for testing application functionalities |
| US11392536B2 (en) * | 2019-10-23 | 2022-07-19 | Motorola Solutions, Inc. | Method and apparatus for managing feature based user input routing in a multi-processor architecture |
| US11630761B2 (en) * | 2021-02-24 | 2023-04-18 | Capital One Services, Llc | Methods, systems, and media for generating test authorization for financial transactions |
| US11698895B2 (en) | 2021-02-24 | 2023-07-11 | Capital One Services, Llc | Access control for a databank system |
| US11775420B2 (en) | 2021-02-24 | 2023-10-03 | Capital One Services, Llc | Methods, systems, and media for accessing data from a settlement file |
| US12052359B2 (en) | 2021-07-30 | 2024-07-30 | APPDIRECT, Inc. | Encryption key rotation |
| US11824941B2 (en) * | 2021-12-22 | 2023-11-21 | Oracle International Corporation | Accessing representational state transfer application programming interfaces using simple mail transfer protocol |
| US11687675B1 (en) * | 2022-09-08 | 2023-06-27 | Pezo Tech Llc | Method and system for improving coupling and cohesion of at least one educational program |
Family Cites Families (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6304893B1 (en) * | 1996-07-01 | 2001-10-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system |
| US7366650B2 (en) * | 2001-04-12 | 2008-04-29 | Arm Limited | Software and hardware simulation |
| US20020169815A1 (en) * | 2001-05-10 | 2002-11-14 | Francis Wong | Method and apparatus for configuration independent simulation of network layer conditions |
| US7334219B2 (en) | 2002-09-30 | 2008-02-19 | Ensco, Inc. | Method and system for object level software testing |
| US8335742B2 (en) * | 2005-03-30 | 2012-12-18 | American Express Travel Related Services Company, Inc. | Method, system, and computer program product for electronic messaging |
| EP1715422A1 (en) * | 2005-04-18 | 2006-10-25 | Research In Motion Limited | System and method for converting a schema based synchronous service to a schema based asynchronous service |
| US7484145B1 (en) | 2005-09-23 | 2009-01-27 | At&T Intellectual Property Ii, L.P. | Method for embedded integrated end-to-end testing |
| US20070169015A1 (en) * | 2005-12-07 | 2007-07-19 | Sbc Knowledge Ventures, L.P. | Web services development automation toolkit with test case driver and customized configuration file |
| US7996816B2 (en) * | 2006-11-15 | 2011-08-09 | International Business Machines Corporation | Method and apparatus for dynamically binding service component implementations for specific unit test cases |
| CN101286131B (zh) * | 2007-04-09 | 2010-06-09 | 国际商业机器公司 | 服务测试方法和服务测试系统 |
| CN102204167B (zh) * | 2008-10-31 | 2015-07-01 | 电子湾有限公司 | 测试应用编程接口(api)调用的方法、系统和响应仿真器 |
| KR101576907B1 (ko) | 2009-02-20 | 2015-12-14 | 엘에스전선 주식회사 | 유연성과 가교 특성이 뛰어난 전선용 절연 재료 및 이를 갖춘 전선 |
| CN103620576B (zh) * | 2010-11-01 | 2016-11-09 | 七网络公司 | 适用于移动应用程序行为和网络条件的缓存 |
| CA2889387C (en) * | 2011-11-22 | 2020-03-24 | Solano Labs, Inc. | System of distributed software quality improvement |
| US20130283238A1 (en) * | 2012-04-19 | 2013-10-24 | Doron Levi | Testing system for an integrated software system |
| US9438488B2 (en) * | 2012-11-09 | 2016-09-06 | Citrix Systems, Inc. | Systems and methods for appflow for datastream |
| US20150128103A1 (en) * | 2013-11-07 | 2015-05-07 | Runscope, Inc. | System and method for automating application programming interface integration |
| US9934135B2 (en) | 2015-08-13 | 2018-04-03 | Ca, Inc. | Generic test automation for application programming interface applications |
| US10387146B2 (en) | 2015-11-30 | 2019-08-20 | Visa International Service Association | System and method for common request processing |
| US10432499B2 (en) * | 2016-06-03 | 2019-10-01 | Ebay Inc. | Application program interface endpoint monitoring |
| US10146674B2 (en) * | 2016-06-16 | 2018-12-04 | Vmware, Inc. | Plugin-based software verification system |
| US10353807B2 (en) | 2016-08-26 | 2019-07-16 | Accenture Global Solutions Limited | Application development management |
-
2018
- 2018-03-06 US US15/913,638 patent/US10467066B2/en active Active
-
2019
- 2019-03-04 SG SG11202008393TA patent/SG11202008393TA/en unknown
- 2019-03-04 EP EP19764336.4A patent/EP3762882B1/en active Active
- 2019-03-04 ES ES19764336T patent/ES2951835T3/es active Active
- 2019-03-04 CN CN201980017352.9A patent/CN111819589B/zh active Active
- 2019-03-04 WO PCT/US2019/020620 patent/WO2019173245A1/en unknown
- 2019-09-20 US US16/578,091 patent/US10884826B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| WO2019173245A1 (en) | 2019-09-12 |
| CN111819589A (zh) | 2020-10-23 |
| CN111819589B (zh) | 2024-01-26 |
| US10884826B2 (en) | 2021-01-05 |
| US20190278637A1 (en) | 2019-09-12 |
| SG11202008393TA (en) | 2020-09-29 |
| EP3762882A1 (en) | 2021-01-13 |
| EP3762882A4 (en) | 2021-04-21 |
| US10467066B2 (en) | 2019-11-05 |
| US20200012546A1 (en) | 2020-01-09 |
| EP3762882B1 (en) | 2023-05-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2951835T3 (es) | Sistema y método para establecer el procesamiento de solicitudes común | |
| US20090271351A1 (en) | Rules engine test harness | |
| CN107341730A (zh) | 一种利用数字汇票申报资金的方法及装置 | |
| WO2019215713A1 (en) | Multiple-part machine learning solutions generated by data scientists | |
| EP3830773A1 (en) | Anonymous distributed consensus regarding the verification of protocols | |
| Alnahawi et al. | On the state of crypto-agility | |
| Ramgir | Internet of Things-Architecture, Implementation, and Security | |
| Issa Mattos et al. | The HURRIER process for experimentation in business‐to‐business mission‐critical systems | |
| Vaher | Next generation digital government architecture | |
| CN104471530A (zh) | 可执行软件规程生成 | |
| US9542660B2 (en) | Work process collaboration management | |
| CN110176998A (zh) | 一种工作量证明的共识方法、装置、设备和存储介质 | |
| CN113988319A (zh) | 联邦学习模型的训练方法、装置、电子设备、介质及产品 | |
| US20130031182A1 (en) | Resolving an exchange of objects in a communication network | |
| CN114677138B (zh) | 一种数据处理方法、设备以及计算机可读存储介质 | |
| US10817661B2 (en) | System architecture framework | |
| Schmeelk et al. | Mobile cyber-assurance informed through knowledge graph construction: the OWASP threat of insecure communications | |
| Pukkila | Secure over-the-air updates for wireless Internet-of-Things devices | |
| US11797364B1 (en) | System and method for connecting xAPI statements with third party applications using representational state transfer APIs | |
| Pesaljevic | e-Prescription Embeddedness in the Norwegian Health Sector | |
| Jothibasu et al. | Vaccination Application for Vaccine Booking and Management | |
| Muhamadi et al. | Student record retrieval system using knowledge sharing | |
| Catanio et al. | A proposed data-driven health-care monitoring system using near field communication | |
| Upreti | Evaluation of Internet of Things Solutions which Includes Cloud Analytic Features | |
| KULASANGAR | Using cryptocurrency along with smart contracts to create a social platform |