ES2960508T3 - Integración de aplicaciones en la nube en una plataforma de intermediación de servicios en la nube por medio de un paquete de conector universal automatizado - Google Patents
Integración de aplicaciones en la nube en una plataforma de intermediación de servicios en la nube por medio de un paquete de conector universal automatizado Download PDFInfo
- Publication number
- ES2960508T3 ES2960508T3 ES18873780T ES18873780T ES2960508T3 ES 2960508 T3 ES2960508 T3 ES 2960508T3 ES 18873780 T ES18873780 T ES 18873780T ES 18873780 T ES18873780 T ES 18873780T ES 2960508 T3 ES2960508 T3 ES 2960508T3
- Authority
- ES
- Spain
- Prior art keywords
- connector
- subscription
- crm
- subscription request
- computing device
- 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 claims abstract description 98
- 238000012545 processing Methods 0.000 claims abstract description 32
- 230000010354 integration Effects 0.000 claims abstract description 13
- 238000013519 translation Methods 0.000 claims abstract description 12
- 230000008859 change Effects 0.000 claims abstract description 11
- 238000012217 deletion Methods 0.000 claims abstract description 6
- 230000037430 deletion Effects 0.000 claims abstract description 6
- 230000000694 effects Effects 0.000 claims abstract description 4
- 238000012360 testing method Methods 0.000 claims description 16
- 238000004891 communication Methods 0.000 claims description 14
- 230000004044 response Effects 0.000 claims description 12
- 238000007726 management method Methods 0.000 claims description 11
- 238000012550 audit Methods 0.000 claims description 8
- 238000012986 modification Methods 0.000 claims description 8
- 230000004048 modification Effects 0.000 claims description 8
- 230000001131 transforming effect Effects 0.000 claims description 4
- 230000009471 action Effects 0.000 claims description 3
- 230000004913 activation Effects 0.000 claims description 3
- 238000009434 installation Methods 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 abstract description 2
- 238000004458 analytical method Methods 0.000 description 17
- 230000008569 process Effects 0.000 description 10
- 238000003860 storage Methods 0.000 description 10
- 230000006870 function Effects 0.000 description 9
- 238000013500 data storage Methods 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 230000002093 peripheral effect Effects 0.000 description 5
- 238000011161 development Methods 0.000 description 4
- 238000009826 distribution Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000003213 activating effect Effects 0.000 description 1
- 238000003339 best practice Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000003780 insertion Methods 0.000 description 1
- 230000037431 insertion Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 230000001737 promoting effect Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000012384 transportation and delivery Methods 0.000 description 1
Classifications
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/567—Integrating service provisioning from a plurality of service providers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5061—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the interaction between service providers and their network customers, e.g. customer relationship management
- H04L41/5064—Customer relationship management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- 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
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/562—Brokering proxy services
-
- 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/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/565—Conversion or adaptation of application format or content
-
- 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/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Technology Law (AREA)
- Stored Programmes (AREA)
- Computer And Data Communications (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Information Transfer Between Computers (AREA)
- Storage Device Security (AREA)
- General Factory Administration (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Un método para integrar aplicaciones en la nube en una plataforma de agente de servicios en la nube (CSB) utilizando un conector universal automatizado. El método incluye recibir en un concentrador de conectores, un paquete de conectores para un software desde un dispositivo de proveedor de software independiente, crear una instancia de conector para el paquete de conector para integración con la plataforma CSB, la plataforma CSB configurada además para proporcionar licencias para el software, recibiendo en el dispositivo informático del intermediario de servicios en la nube a través de una interfaz de plataforma CSB, una solicitud de suscripción para el software, comprendiendo la solicitud de suscripción una actividad seleccionada de un grupo que consiste en una creación, cambio y eliminación, transmisión a un dispositivo conector universal mediante un controlador de plataforma CSB, la solicitud de suscripción, procesamiento, en el dispositivo conector universal, la solicitud de suscripción, notificación a un dispositivo de gestión de relaciones con el cliente (CRM), mediante el dispositivo conector universal, de la solicitud de suscripción, almacenar la solicitud de suscripción en una base de datos CRM, obtener la aprobación por parte del dispositivo conector universal, para la solicitud de suscripción, procesar, en el dispositivo conector universal, la solicitud de suscripción, al recibir una aprobación de la solicitud, y transmitir un resultado de aprobación de suscripción a la plataforma CSB, mostrando la plataforma CSB el resultado de aprobación de suscripción a un suscriptor. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Integración de aplicaciones en la nube en una plataforma de intermediación de servicios en la nube por medio de un paquete de conector universal automatizado
Referencia cruzada a solicitud relacionada
La presente solicitud es una solicitud de patente internacional, la cual reivindica el beneficio prioritario de la Solicitud de Estados Unidos con Número de Serie 62/578.992, presentada el 30 de octubre de 2017.
Campo técnico de las realizaciones desveladas
Las realizaciones desveladas actualmente se refieren en general a la intermediación de servicios en la nube y, más concretamente, a un sistema y un procedimiento para integrar aplicaciones en la nube en una plataforma de intermediación de servicios en la nube mediante el uso de un conector universal automatizado.
Antecedentes de las realizaciones desveladas
Los proveedores de software independientes (ISV) desarrollan y comercializan aplicaciones de software las cuales están típicamente diseñadas para funcionar en una o más plataformas de hardware o de sistema operativo. Tales aplicaciones de software están en un intervalo desde la utilidad básica o la aplicación para mejorar la productividad hasta la aplicación de procedimientos de negocio para empresas (por ejemplo, gestión de relaciones con el cliente (CRM), planificación de recursos empresariales (ERP), herramientas de automatización, etc.). A medida que la informática en la nube se ha ido generalizando, uno de tales procedimientos de entrega de software ha sido a través de la nube mediante el uso de un software como modelo basado en servicios (SaaS). Mediante el uso de este procedimiento de entrega, los ISV pueden comercializar sus aplicaciones de software, o suscripciones a sus aplicaciones de software, a través de una nube pública o un mercado en la nube, o a través de un intermediario de servicios en la nube (CSB).
Mientras que el mercado en la nube proporciona un escaparate en línea para el acceso de los clientes a los servicios y aplicaciones de software basados en la nube, se puede usar un intermediario de servicios en la nube para facilitar la transacción entre el ISV y un usuario final, revendedor, minorista, etc., tal como mediante el uso de un plug-in o conector para cada aplicación en la nube. En las implementaciones tradicionales de intermediarios de servicios en la nube, el ISV suele preparar componentes de integración especiales: paquetes de conectores (tales como metadatos, descripciones de procedimientos de control y archivos de contenido, que se usan para declarar y definir los recursos de aplicaciones, servicios, componentes de interfaz de usuario y lógica de procedimientos de control necesarios para gestionar los recursos de aplicaciones en la nube); y unback-endde conectores para traducir las llamadas a la interfaz de programación de aplicaciones (API) con procedimientos de control recibidas del CSB a llamadas a la API específicas de la aplicación o aplicaciones en la nube del ISV en particular. El Documento US 2015/156065 forma parte de la técnica anterior.
Sin embargo, muchas aplicaciones ISV no disponen de servicios API totalmente automatizados. Por lo tanto, la integración con la plataforma de CSB resulta problemática. Por ejemplo, los ISV tienen que desarrollar una API y posteriormente componentes de integración. En tales situaciones, el desarrollo del conector a la plataforma de CSB lleva mucho tiempo y representa una porción significativa del tiempo total de integración. Además, probar y validar el conector añade tiempo adicional al proceso de integración. Por lo tanto, existe la necesidad de un sistema y un procedimiento para integrar aplicaciones en la nube en una plataforma de intermediación de servicios en la nube por medio de un conector universal automatizado.
Sumario de las realizaciones desveladas
En un aspecto, se proporciona un procedimiento para integrar aplicaciones en la nube en una plataforma de intermediario de servicios en la nube (CSB) mediante el uso de un conector universal automatizado. El procedimiento incluye recibir en un concentrador de conectores, un paquete de conectores para software de un dispositivo de vendedor de software independiente, crear una instancia de conector para el paquete de conectores para la integración con la plataforma de CSB, la plataforma de CSB además está configurada para proporcionar licencias para el software.
En algunas realizaciones, el procedimiento además incluye las etapas de recibir en el dispositivo informático del intermediario de servicios en la nube a través de una interfaz de plataforma de CSB, una solicitud de suscripción para el software, la solicitud de suscripción comprende una actividad seleccionada de un grupo que consiste en una creación, cambio y eliminación, transmitir a un dispositivo del conector universal por un controlador de plataforma de CSB, la solicitud de suscripción, y procesar, en el dispositivo del conector universal, la solicitud de suscripción.
En algunas realizaciones, el procedimiento además incluye las etapas de notificar a un dispositivo de gestión de relaciones con el cliente (CRM), por el dispositivo del conector universal, de la solicitud de suscripción, almacenar la solicitud de suscripción en una base de datos de CRM, obtener la aprobación por el dispositivo del conector universal, para la solicitud de suscripción, y procesar, en el dispositivo del conector universal, la solicitud de suscripción, al recibir una aprobación de la solicitud.
En algunas realizaciones, la transmisión de un resultado de aprobación de suscripción a la plataforma de CSB incluye que la plataforma de CSB muestre el resultado de aprobación de suscripción a un suscriptor. El procedimiento además incluye que el paquete de conectores se desarrolle en un portal para desarrolladores, el portal para desarrolladores es accesible por el dispositivo de vendedor de software independiente.
En algunas realizaciones, la solicitud de suscripción además incluye un modelo de recurso correspondiente definido en el paquete de conectores.
En algunas realizaciones, la solicitud de suscripción es recibida por un controlador de la aplicación del conector, la etapa de procesar la solicitud de suscripción en un intérprete del modelo de recursos, y el procesamiento además comprende la etapa de procesar los datos de la solicitud con un motor de traducción de la interfaz de programación de aplicaciones (API).
En algunas realizaciones, el procedimiento además incluye procesar, en el dispositivo del conector universal, los contadores de análisis y los límites del modelo de recursos del paquete de conectores correspondiente.
En algunas realizaciones, el procedimiento además incluye procesar, en el dispositivo del conector universal, los contadores y límites de análisis del modelo de recursos del paquete de conectores correspondiente, y además comprende la etapa de procesar los contadores y límites con un motor de traducción de interfaz de programación de aplicaciones (API).
En algunas realizaciones, la traducción comprende la etapa de transformar las solicitudes de la plataforma de CSB en un formato operable por el dispositivo de CRM, y además mostrar las solicitudes en una interfaz de usuario (UI) CRM.
En algunas realizaciones, el procedimiento además incluye las etapas de que el conector universal transmita una solicitud pendiente al dispositivo de CRM, y sondee una respuesta del operador desde el dispositivo API de CRM; recibir y transformar las instrucciones de instalación para la activación/cambio de suscripción recibidas desde el servidor API de CRM en un formato visualizable por la UI de la plataforma de CSB; transformar las modificaciones de cuenta recibidas desde un servidor API de CRM en un formato visualizable por la UI de la plataforma de CSB; y almacenar las modificaciones de cuenta en una base de datos de suscripción conectada operablemente al dispositivo del conector universal.
En algunas realizaciones, el procedimiento además incluye el análisis y la correspondencia de un identificador único de suscripción asociado con un sistema de gestión de suscripciones ISV, el identificador único de suscripción asociado con un sistema de gestión de suscripciones de plataforma de CSB; el conector universal que proporciona una respuesta, la respuesta seleccionada de un grupo que consiste en una creación, modificación y eliminación; y el almacenamiento de datos asociados con la solicitud de suscripción y la respuesta en una base de datos de una región que cumple los requisitos del país en el que opera la plataforma de CSB.
En algunas realizaciones, un módulo de auditoría operablemente conectado con el dispositivo de CRM registra las acciones del operador en la base de datos de CRM, en la que los datos de auditoría se usan para analizar problemas técnicos con los componentes de integración; y en la que el dispositivo de CRM además comprende un módulo de seguridad para la autenticación de conectores universales.
Breve descripción de los dibujos
Las realizaciones y otras características, ventajas y divulgaciones contenidas en la presente memoria, así como la forma de obtenerlas, se harán evidentes y la presente divulgación se entenderá mejor por referencia a la siguiente descripción de varias realizaciones ejemplares de la presente divulgación tomadas en conjunto con los dibujos adjuntos, en los que:
La FIG. 1 es un diagrama de bloques de una realización ilustrativa de un mercado de servicios en la nube y un sistema de intermediación para la distribución de aplicaciones en la nube a través de sistemas de intermediación de servicios en la nube;
La FIG. 1 es un diagrama de bloques de otra realización ilustrativa de un mercado de servicios en la nube y un sistema de intermediación para la distribución de aplicaciones en la nube a través de sistemas de intermediación de servicios en la nube;
La FIG. 1B es un diagrama de bloques de una realización ilustrativa de un sistema para integrar aplicaciones en la nube en una plataforma de intermediación de servicios en la nube mediante el uso de un conector universal automatizado;
La FIG. 2 es un diagrama de bloques de una realización ilustrativa de uno de los dispositivos informáticos del sistema de intermediación de servicios en la nube de la FIG. 1;
La FIG. 3 es un diagrama de bloques de un entorno ilustrativo del dispositivo informático del portal para desarrolladores de la FIG. 1;
Las FIGS. 4A a 4B son un diagrama de flujo esquemático de un procedimiento ilustrativo para crear y distribuir conectores en sistemas de intermediación de servicios en la nube que pueden ser llevados a cabo por el dispositivo informático del portal para desarrolladores de la FIG. 1;
La FIG. 5 es un diagrama de flujo esquemático de un procedimiento ilustrativo para llevar a cabo un análisis de versión en objetos conectores que puede ser llevado a cabo por el dispositivo informático del portal para desarrolladores de la FIG. 1; y
La FIG. 6 es un diagrama de flujo esquemático de otro procedimiento ilustrativo para llevar a cabo un análisis de emparejamiento en objetos conectores que puede ser llevado a cabo por el dispositivo informático del portal para desarrolladores de la FIG. 1.
La FIG. 7 es un diagrama de flujo esquemático de una realización ilustrativa de un sistema para integrar aplicaciones en la nube en una plataforma de intermediación de servicios en la nube mediante el uso de un conector universal automatizado;
La FIG. 8 es un diagrama de flujo esquemático de otra realización ilustrativa de un sistema para integrar aplicaciones en la nube en una plataforma de intermediación de servicios en la nube mediante el uso de un conector universal automatizado.
Descripción detallada de las realizaciones desveladas
Con el propósito de promover la comprensión de los principios de la presente divulgación, se hará referencia ahora a las realizaciones ilustradas en los dibujos, y se usará un lenguaje específico para describirlas. No obstante, se entenderá que no se pretende limitar el ámbito de la presente divulgación.
La FIG. 1 ilustra un sistema de intermediación y mercado de servicios en la nube 100 para crear y distribuir conectores de integración. El sistema de intermediación y mercado de servicios en la nube 100 incluye un dispositivo informático del portal para desarrolladores 116, un dispositivo informático de ISV 122 y un dispositivo informático de intermediario 130, cada uno de los cuales está acoplado comunicativamente a un dispositivo informático de mercado 102 (por ejemplo, a través de una red 128), un servidor API de CRM 138 y un dispositivo informático conector universal 136. En una realización de la presente divulgación, un desarrollador/programador de aplicaciones en la nube asociado con un ISV puede desarrollar paquetes de conectores para integrar la aplicación en la nube del ISV en el sistema de intermediación de servicios en la nube 100.
Para desarrollar el paquete de conectores, el desarrollador usa un portal de desarrollador (por ejemplo, el portal de interfaz de usuario (UI) para desarrolladores 118 del dispositivo informático del portal para desarrolladores 116) para un servicio particular que se ofrecerá a la venta en un mercado de servicios en la nube (por ejemplo, a través del mercado de intermediario de servicios en la nube 104 del dispositivo informático de mercado 102). Se debe apreciar que el desarrollador puede acceder al portal de la UI para desarrolladores 118 a través de un dispositivo informático de punto final (no mostrado) acoplado comunicativamente (por ejemplo, a través de la red 128) al dispositivo informático del portal para desarrolladores 116.
En al menos una realización de la presente divulgación, el paquete de conectores suele tener la forma de un archivo de almacenamiento que normalmente incluye metadatos, descripciones de procedimientos de control y archivos de contenido, que son utilizables para declarar y definir los recursos de la aplicación, los servicios, los componentes de la interfaz de usuario y la lógica de los procedimientos de control necesarios para gestionar los recursos de la aplicación en la nube. Se apreciará que un paquete de conectores consiste en los archivos declarativos usados para definir los atributos de la aplicación del iSv y del"front-enddel conector": la interfaz web que los clientes del intermediario de servicios en la nube ven en la interfaz del intermediario de servicios en la nube. Esta interfaz web es desarrollada por los desarrolladores del paquete de conectores mediante el uso de un marco especial que incluyewidgets,una estructura de página predefinida, procedimientos de navegación y un mecanismo de inserción de pantallas. Un conectorfront-endtípico consiste en pantallas insertadas en vistas predefinidas, lógica personalizada para renderizarwidgetsy estructura de navegación personalizada. Loswidgetspueden mostrar información que el desarrollador del conector considere valiosa para el cliente de la aplicación en nube correspondiente, por ejemplo, informes de uso, información sobre suscripciones y servicios, instrucciones, etc.
Mediante el uso de las instrucciones que proporciona el mercado de intermediarios de servicios en la nube, el paquete de conectores se puede convertir en la aplicación del conector, es decir, en la instancia de dicho conector (véase, por ejemplo, una instancia de conector correspondiente 114 de la fábrica de conectores 112 de la FIG. 1 y la FIG. 1A), que se puede usar para comunicarse con el conector universal acoplado.
El portal para desarrolladores está configurado para recibir información del desarrollador que se puede usar para definir los componentes principales del paquete del conector, tal como un modelo (por ejemplo, una explicación del modelo de negocio para objetos de aplicación), una interfaz de usuario que soporte las interacciones del usuario y unback-end(por ejemplo, un servicio de transferencia de estado representacional (REST) para el aprovisionamiento de procesos, la gestión, la supervisión de solicitudes, etc.) para el conector. Se debe apreciar que el portal para desarrolladores puede estar configurado para recibir información adicional asociada con el conector, tal como la dirección del servicio en la nube, la configuración predeterminada, la información de precios, las plantillas de ventas, un identificador del servicio en la nube, etc.
El portal de desarrollador está configurado adicionalmente para, como se describirá con más detalle a continuación, producir un paquete de conectores, probar el paquete de conectores producido y publicar el paquete de conectores probado en un catálogo de conectores (por ejemplo, la base de datos de servicios disponibles 110 del concentrador de conectores 106 del dispositivo informático de mercado 102). Tras la fase de desarrollo, el paquete de conectores puede pasar a la fase de producción, en la que el conector se puede desplegar en un intermediario de servicios en la nube (por ejemplo, a través del mercado de intermediario de servicios en la nube 104 por medio de la interfaz de intermediario de servicios en la nube 132 del dispositivo informático de intermediario 130).
El dispositivo informático de intermediario 130 está configurado para gestionar licencias de diversas aplicaciones en la nube entre el intermediario de servicios en la nube y los clientes, tales como, por ejemplo, revendedores, usuarios finales de aplicaciones en la nube y similares. En un ejemplo ilustrativo, un ISV (por ejemplo, un proveedor de servicios en la nube) contrata con una entidad controladora del mercado de servicios en la nube 102 para facilitar la venta de una licencia a un usuario final proporcionando un paquete de conectores que permite a los clientes del mercado de intermediarios de servicios en la nube (por ejemplo, intermediarios de servicios en la nube) cargar el paquete de conectores e integrar el proceso de gestión de esta aplicación en la nube en la plataforma de intermediarios de servicios en la nube. La licencia puede entonces permitir a ese usuario final, o a otro(s) usuario(s) final(es) asociado(s) a él, cierto acceso a los servicios en la nube del ISV (por ejemplo, aplicaciones de software como servicio (SaaS) basadas en la nube).
Para ello, el dispositivo informático de mercado 102 ilustrativo incluye un concentrador de conectores 106 que está configurado para almacenar conectores empaquetados generados a través del portal de UI para desarrolladores 118 (por ejemplo, en la base de datos de servicios disponibles 110) y para establecer canales de aprovisionamiento para conectores 114 de una fábrica de conectores 112 entre una interfaz de ISV 124 del dispositivo informático de ISV 122 y una interfaz de intermediario de servicios en la nube 132 del dispositivo informático de intermediario 130. En consecuencia, un intermediario de servicios en la nube puede comercializar licencias para aplicaciones en la nube asociadas con los conectores empaquetados a usuarios finales (por ejemplo, un cliente, un intermediario, un revendedor, etc.) a través de su respectiva interfaz de intermediario de servicios en la nube 132.
El concentrador de conectores 106 está configurado adicionalmente para generar credenciales de canal de aprovisionamiento para cada intermediario de servicios en la nube 130 (por ejemplo, credenciales de intermediario y/o credenciales de ISV en la nube y/o credenciales de conector universal y/o credenciales de servidor API de CRM 138, tales como las que se pueden almacenar en la base de datos de credenciales 108). Se debe apreciar que las credenciales del canal de aprovisionamiento pueden ser cualquier tipo de información (por ejemplo, claves criptográficas u otros datos arbitrarios) que sea utilizable para autenticar un canal de comunicación seguro entre dos entidades que usen las credenciales del canal de aprovisionamiento.
En al menos una realización de la presente divulgación, el canal de aprovisionamiento puede ser configurado por el mercado de intermediarios de servicios en la nube. El canal de aprovisionamiento se conecta desde el conector universal 136 y el servidor API de CSM 138 desde el que el operador del ISV puede recibir órdenes, lo que incluye actividades tales como, por ejemplo, la creación de una nueva suscripción, la eliminación de una suscripción existente, la modificación de una suscripción existente, el suministro de instrucciones de activación para el cliente, la visualización y modificación de los datos personales de los clientes distribuidos geográficamente.
Se apreciará que el propósito del conector universal 136 es traducir la API de la plataforma del intermediario de servicios en la nube a la API del servidor API de CRM 136. Se apreciará además que el conector universal 136 es capaz de procesar cualquier modelo de recursos de cualquier paquete de conectores de cualquier aplicación en la nube que reciba del intermediario de servicios en la nube y puede convertirlo al formato aplicable al servidor API de CRM 136. El conector universal 136 transforma el flujo del ciclo de vida de la aplicación del ISV en la plataforma de CSB en entidades en el servidor API de CRM 136, y por medio de la reacción del operador a estas entidades puede proporcionar a la plataforma de CSB la información necesaria sobre el estado actual de la aplicación. Se apreciará que dicho canal de aprovisionamiento permite automatizar el aprovisionamiento de aplicaciones en la nube para los ISV que no disponen de API ni de ningún otro instrumento de integración.
Como se muestra en el sistema de intermediación y mercado de servicios en la nube 100 ilustrativo, cada uno del dispositivo informáticos de mercado 102, el dispositivo informático del portal para desarrolladores 116, el dispositivo informático de ISV 122, el dispositivo informático de intermediario 130, el dispositivo informático del conector universal 136, el servidor API de CRM 136 se pueden incorporar como dispositivos informáticos 134. Por consiguiente, se debe apreciar que cada uno de los respectivos dispositivos informáticos 134 se puede incorporar como cualquier tipo de dispositivo informático y/o almacenamiento capaz de llevar a cabo las funciones descritas en la presente memoria. Además, se debe apreciar que cada uno de los respectivos dispositivos informáticos 134 puede estar compuesto por más de un dispositivo informático 134. Por ejemplo, uno o más de los dispositivos informáticos 134 pueden estar incorporados como un incorporado como uno o más servidores (por ejemplo, independientes, montados en bastidor, etc.) y/o una combinación de cuchillas de informática y dispositivos de almacenamiento de datos (por ejemplo, de una red de área de almacenamiento (SAN)) en una red con arquitectura de nube o centro de datos, a la vez que uno o más de los respectivos dispositivos informáticos pueden estar incorporados como un ordenador de mesa, un dispositivo informático móvil (por ejemplo, teléfono inteligente, dispositivos portátiles, tabletas, portátiles, ordenadores portátiles, etc.), o cualquier otro tipo de dispositivo "inteligente" o conectado a Internet.
La FIG. 1A es otra realización de un mercado de servicios en la nube y un sistema de intermediación para la distribución de aplicaciones en la nube a través de sistemas de intermediación de servicios en la nube. La única diferencia es que el mercado de intermediarios de servicios en nube establece instancias de conectores para los intermediarios de servicios en nube en sus propias instalaciones. De acuerdo con esta realización, todos los datos sobre la cuenta, el modelo de recursos y otros datos recopilados por la interfaz de la plataforma del intermediario de servicios en la nube y que se deben traducir al ISV para la gestión de la suscripción a la aplicación en la nube son traducidos por el controlador del intermediario de servicios en la nube a través de la instancia del conector correspondiente al conector universal. En ese caso, el concentrador de conectores 106 genera un par de claves secretas entre el intermediario de servicios en la nube y cada instancia de conector desplegada por la solicitud del intermediario de servicios en la nube.
En al menos una realización de la presente divulgación, en la FIG. 1B se muestra un diagrama de bloques de una realización ilustrativa de un sistema para traducir el flujo del ciclo de vida de la aplicación del ISV en la plataforma de CSB al ISV mediante el uso de un conector universal automatizado. El sistema 140 además incluye un servidor API de CRM 138, un dispositivo informático de intermediario 130, un navegador 164, una base de datos de CRM 166 y un conector universal 136.
En al menos una realización de la presente divulgación, el servidor API de CRM 138 incluye un motor de notificación de CRM 152, un gestor de pedidos 153, un módulo de auditoría 156 y un módulo de seguridad 158. En al menos una realización de la presente divulgación, el dispositivo informático de intermediario 130 incluye una plataforma 130A que incluye al menos una de una pluralidad de instancias de conector 112 y el controlador de intermediario de servicios en la nube 106. El controlador de intermediario de servicios en la nube de la plataforma 130A está configurado para transmitir solicitudes y todos los datos necesarios de creación (aprovisionamiento), eliminación y cambio de la suscripción de servicios en la nube al conector universal.
En al menos una realización de la presente divulgación, el conector universal 136 está configurado para gestionar cada configuración de modelo y transformar las solicitudes de suscripción entrantes en pedidos CRM. El conector universal 136 además incluye un controlador de aplicación del conector 172, un intérprete del modelo de recursos 174, un motor de sondeo y notificación 176 y un motor de traducción de API 178. En al menos una realización de la presente divulgación, el conector universal 136 está configurado para recibir de un controlador de intermediario de servicio en la nube 106 el modelo de recurso del paquete de conector correspondiente asociado con la al menos una instancia de conector 114 que se refiere al servicio en la nube cuya suscripción se está creando, modificando o eliminando. En al menos una realización de la presente divulgación, el intérprete del modelo de recursos 174 está configurado para analizar este modelo de recursos e identificar contadores (por ejemplo, espacio en disco, máquinas virtuales, buzones de correo, etc.) y límites (2 buzones de correo, 1 GB de espacio en disco, etc.) de los recursos incluidos en la suscripción que se está procesando y recuperar los contadores y límites identificados para el controlador de aplicación del conector 172.
En al menos una realización de la presente divulgación, el controlador de aplicación del conector 172 está configurado para recibir datos sobre la suscripción procesada (por ejemplo, nombre de la aplicación en la nube asociada, recursos, etc.), contadores identificados y límites de recursos, y transmitir estos datos a un motor de traducción de API 178.
En al menos una realización de la presente divulgación, el motor de traducción de API 178 está configurado para procesar los datos recibidos y convertirlos al formato que el sistema CRM pueda entender y reflejarlos como pedidos. Se apreciará que el motor de traducción de API 178 procesa los datos de forma que un operador que use el sistema CRM pueda identificar fácilmente qué tipo de acciones (en respuesta a órdenes) y con qué aplicación en la nube y recursos y servicios proporcionados por esta aplicación en la nube se requieren.
El motor de sondeo y notificación interfaz de ISV notifica al servidor API de CRM 138 sobre nuevos pedidos y a cambio recibe datos sobre el estado de estos pedidos.
El servidor API de CRM 138 almacena los pedidos y la información sobre los clientes de las suscripciones procesadas en su base de datos 166. En al menos una realización de la presente divulgación, el servidor API de CRM 138 incluye un módulo de auditoría 156 que está configurado para almacenar todas las modificaciones en los pedidos llevados a cabo por el operador (datos de cuenta cambiados en comparación con los datos de cuenta recibidos del conector universal, cambios en la suscripción (errores en los contadores, límites, etc.), etc.). El módulo de seguridad 158 autentica cualquier conector universal (por ejemplo, el dispositivo del conector universal 136). El motor de notificación de CRM 152 muestra notificaciones sobre pedidos a un operador.
En al menos una realización de la presente divulgación, el sistema 140 incluye una base de datos de CRM 166. La base de datos de CRM 166 está configurada para procesar pedidos e información de clientes recibida del conector universal 136, en la que los parámetros incluyen información sobre la geografía de un intermediario de servicios en la nube. A modo de ejemplo, si el intermediario de servicios en nube está ubicado en Europa, la información sobre los pedidos iniciados por dicho intermediario de servicios en nube se almacena en una base de datos ubicada en Europa, donde dicho requisito puede estar motivado por requisitos legales y/o reglamentarios. Se apreciará que la base de datos de CRM 166 puede ser una única base de datos, una base de datos distribuida, o una disposición de base de datos alternativa, configurada para funcionar como se desvela en la presente memoria.
En al menos una realización de la presente divulgación, el navegador 164 se puede desplegar en el lado de un operador, en el que el navegador 164 se usa para comunicarse de forma operable con el servidor API de CRM 138 (por ejemplo, a través de la red 128), de forma que el operador pueda llevar a cabo funciones administrativas en el sistema de creación de suscripciones nativas ISV en respuesta a los pedidos tales como, por ejemplo, crear suscripciones, actualizar/eliminar suscripciones, y similares.
Con referencia a continuación a la FIG. 2, se muestra una realización ilustrativa de un dispositivo informático 134 representativo de uno o más del dispositivo informáticos de mercado 102, el dispositivo informático del portal para desarrolladores 116, el dispositivo informático de ISV 122, y el dispositivo informático de intermediario 130. El dispositivo informático 134 ilustrativo incluye una unidad central de procesamiento (CPU) 200, un controlador de entrada/salida (E/S) 202, una memoria 204, un circuito de comunicación de red 206, y un dispositivo de almacenamiento de datos 210, así como, en algunas realizaciones, uno o más periféricos de E/S 208. En algunas realizaciones, uno o más de los componentes ilustrativos se pueden combinar en un único sistema en un chip (SoC) en un único circuito integrado (IC). Se debe apreciar que las realizaciones alternativas pueden incluir componentes adicionales, menores, y/o alternativos a los del dispositivo informático 134 ilustrativo, tal como una unidad de procesamiento gráfico (GPU), una fuente de alimentación, etc., los cuales no se muestran para preservar la claridad de la descripción. Además, se debe apreciar que el tipo de componentes de almacenamiento/informático del respectivo dispositivo informático 134 se puede basar en el tipo y el uso previsto del respectivo dispositivo informático 134.
La CPU 200, o procesador, puede ser incorporado como cualquier tipo de hardware o combinación de circuitos capaces de procesar datos. En consecuencia, la CPU 200 puede incluir un núcleo de procesamiento (no se muestra) en una arquitectura de procesador de un solo núcleo, o múltiples núcleos de procesamiento en una arquitectura de procesador de múltiples núcleos. Independientemente del número de núcleos de procesamiento, la CPU 200 es capaz de leer y ejecutar instrucciones de programa. En algunas realizaciones, la CPU 200 puede incluir una memoria caché (no se muestra) que puede estar integrada de manera directa con la CPU 200 o colocada en un chip separado con una interconexión separada a la CPU 200. Se debe apreciar que, en algunas realizaciones, la lógica de canalización se puede usar para llevar a cabo operaciones de software y/o hardware (por ejemplo, operaciones de procesamiento de tráfico de red), en lugar de comandos emitidos a/a partir de la CPU 200.
El controlador de E/S 202, o la interfaz de E/S, puede ser incorporado como cualquier tipo de hardware informático o combinación de circuitos capaces de interconectar entre los dispositivos de entrada/salida y el dispositivo informático 134. Ilustrativamente, el controlador de E/S 202 está configurado para recibir solicitudes de entrada/salida a partir de la CPU 200, y enviar señales de control a los respectivos dispositivos de entrada/salida, para de modo gestionar el flujo de datos a/a partir del dispositivo informático 134.
La memoria 204 puede ser incorporada como cualquier tipo de hardware informático o combinación de circuitos capaces de contener datos e instrucciones para su procesamiento. Tal memoria 204 se puede denominar como memoria principal o primaria. Se debe apreciar que, en algunas realizaciones, uno o más componentes del dispositivo informático 134 pueden tener acceso directo a la memoria, de forma que ciertos datos se puedan almacenar a través de un acceso directo a la memoria (DMA) independientemente de la CPU 200.
El circuito de comunicación de red 206 puede ser incorporado como cualquier tipo de hardware informático o combinación de circuitos capaces de gestionar comunicaciones de interfaz de red (por ejemplo, mensajes, datagramas, paquetes, etc.) a través de modos de comunicación inalámbricos y/o cableados. En consecuencia, en algunas realizaciones, el circuito de comunicación de red 206 puede incluir un controlador de interfaz de red (NIC) capaz de ser configurado para conectar el dispositivo informático 134 a una red informática (por ejemplo, la red 128), así como otros dispositivos informáticos del sistema de intermediación y mercado de servicios en la nube 100.
Los uno o más periféricos de E/S 208 se pueden incorporar como cualquier dispositivo auxiliar configurado para conectarse a y comunicarse con el dispositivo informático 134. Por ejemplo, los periféricos de E/S 208 pueden incluir, pero no limitarse a, un ratón, un teclado, un monitor, una pantalla táctil, una impresora, un escáner, un micrófono, un altavoz, etc. En consecuencia, se debe apreciar que algunos dispositivos de E/S son capaces de una función (es decir, de entrada o de salida), o de ambas funciones (es decir, de entrada y de salida).
En algunas realizaciones, los periféricos de E/S 208 pueden estar conectados al dispositivo informático 134 a través de un cable (por ejemplo, un cable de cinta, un cable, un cable de bus serie universal (USB), un cable de interfaz multimedia de alta definición (HDMI), etc.) del dispositivo informático 134. En tales realizaciones, el cable se conecta a un puerto correspondiente (no se muestra) del dispositivo informático 134 para el cual las comunicaciones llevadas a cabo entre ellos pueden ser gestionadas por el controlador de E/S 202. En realizaciones alternativas, los periféricos de E/S 208 pueden estar conectados al dispositivo informático 134 a través de un modo de comunicación inalámbrico (por ejemplo, Bluetooth®, Wi-Fi®, etc.) el cual puede ser gestionado por el circuito de comunicación de red 206.
El dispositivo de almacenamiento de datos 210 puede ser incorporado como cualquier tipo de hardware informático capaz de almacenar datos de manera no volátil (por ejemplo, medios de almacenamiento semiconductores, medios de almacenamiento magnéticos, medios de almacenamiento ópticos, etc.). Tales dispositivos de almacenamiento de datos 210 se denominan comúnmente almacenamiento auxiliar o secundario, y se usan típicamente para almacenar una gran cantidad de datos en relación con la memoria 204 descrita anteriormente.
De nuevo con referencia a la FIG. 1, el sistema de mercado de servicios en la nube 100 ilustrativo incluye una red 128 que es utilizable por los otros dispositivos informáticos 134 (es decir, el dispositivo informático del portal para desarrolladores 116, el dispositivo informático de ISV 122 y el dispositivo informático de intermediario 130) para comunicarse con el dispositivo informático de mercado 102. La red 128 se puede implementar como cualquier tipo de red cableada y/o inalámbrica, que incluye una red de área local (LAN), una red de área amplia (WAN), una red de área metropolitana (MAN), una red global (Internet), etc., mediante el uso de cualquier tecnología de comunicación cableada y/o inalámbrica y protocolos de transmisión de comunicación de red. En consecuencia, la red 128 puede incluir uno o más dispositivos informáticos de red acoplados comunicativamente (no mostrados) para facilitar el flujo y/o procesamiento del tráfico de comunicación de red a través de una serie de interconexiones cableadas y/o inalámbricas. Tales dispositivos informáticos de red pueden incluir, pero no limitarse a, uno o más puntos de acceso, enrutadores, conmutadores, servidores, dispositivos informáticos, dispositivos de almacenamiento, etc.
Por ejemplo, uno o más de estos dispositivos informáticos de red pueden estar configurados para acoplar uno o más del dispositivo informático de mercado 102, el dispositivo informático del portal para desarrolladores 116, el dispositivo informático de ISV 122, y/o el dispositivo informático de intermediario 130 a la red 128 en una configuración LAN mediante el uso de tecnologías de comunicación por cable (por ejemplo, Ethernet, token ring, etc.) y/o inalámbricas (por ejemplo, Bluetooth®, Wi-Fi®, banda ancha inalámbrica, ZigBee®, etc.) y protocolos asociados. En cumplimiento del ejemplo, la LAN puede estar acoplada (por ejemplo, a través de coaxial, telefonía móvil, fibra, etc.) a una o más redes de área mayor (por ejemplo, WAN, redes de área metropolitana (MAN), Internet, etc.) a través de dispositivos informáticos de red adicionales de la red 128. Se debe apreciar que uno o más de los dispositivos informáticos de red y/o configuraciones de red se pueden virtualizar (por ejemplo, un conmutador virtual, una LAN virtual, etc.).
Como se ha descrito anteriormente, el dispositivo informático del portal para desarrolladores 116 incluye un portal de UI para desarrolladores, el dispositivo informático de ISV 122 incluye una interfaz de ISV en la nube 124 y el dispositivo informático de intermediario 130 ilustrativo incluye una interfaz de intermediario de servicios en la nube 132. Cada uno del portal de UI para desarrolladores 118, la interfaz de ISV en la nube 124, y la interfaz del intermediario de servicios en la nube 132 puede ser incorporada como cualquier combinación de software, hardware, firmware, y circuitos capaces de llevar a cabo las funciones descritas en la presente memoria. En algunas realizaciones, uno o más del portal de UI para desarrolladores 118, la interfaz de ISV en la nube 124 y la interfaz de intermediario de servicios en la nube 132 se pueden configurar para mostrar información (por ejemplo, a través de una UI gráfica, una interfaz de línea de comandos, etc.) en una pantalla de su dispositivo informático 134 respectivo. En tales realizaciones, el portal de UI para desarrolladores 118, la interfaz de<i>S<v>en la nube 124 y la interfaz de intermediario de servicios en la nube 132, pueden estar configuradas para transmitir las entradas recibidas a partir de un usuario para iniciar sesión, configurar la interfaz respectiva, o manipular la información (por ejemplo, la configuración) asociada a la misma.
Con referencia a continuación a la FIG. 3, se muestra un entorno ilustrativo 300 del dispositivo informático del portal para desarrolladores 116. El entorno ilustrativo 300 incluye un constructor de conectores 304, un reproductor de conectores 314, un sistema de pruebas 316 y un sistema experto 318, así como el portal de UI para desarrolladores 118 de la FIG. 1. En algunas realizaciones, uno o más del portal de UI para desarrolladores 118, el constructor de conectores 304, el reproductor de conectores 314, el sistema de pruebas 316 y el sistema experto 318 pueden incluir uno o más medios legibles por ordenador (por ejemplo, la memoria 204, el dispositivo de almacenamiento de datos 210, y/o cualquier otro dispositivo de almacenamiento de medios) que tengan instrucciones almacenadas en ellos y uno o más procesadores (por ejemplo, la CPU 200) acoplados con los uno o más medios legibles por ordenador y configurados para ejecutar instrucciones para llevar a cabo las funciones descritas en la presente memoria. Además, el entorno ilustrativo 300 incluye una base de datos de modelos 302 y un gestor de bibliotecas 306, cada uno de los cuales se describirá con más detalle a continuación.
Como se describió previamente, el portal de UI para desarrolladores 118 puede estar incorporado como cualquier tipo de firmware, hardware, software, circuitos o combinación de los mismos capaz de llevar a cabo las funciones en la presente memoria descritas. Además, cada uno del constructor de conectores 304, el reproductor de conectores 314, el sistema de pruebas 316, y el sistema experto 318 también pueden ser incorporados como cualquier tipo de firmware, hardware, software, circuitos, o combinación de los mismos capaces de llevar a cabo las respectivas funciones descritas en la presente memoria.
Como también se ha descrito anteriormente, el portal de UI para desarrolladores 118 está configurado para proporcionar una interfaz a un desarrollador para generar un conector de API empaquetado para un servicio en la nube. Para ello, el portal de UI para desabolladores 118 está configurado para comunicarse con un desa<b>ollador (por ejemplo, a través de solicitudes/respuestas del protocolo de transferencia de hipertexto [HTTP]) e interactuar con los diversos componentes y medios de almacenamiento del entorno 300.
Por ejemplo, el portal de UI para desarrolladores 118 está configurado para comunicarse con el desarrollador para recibir información (es decir, información de descripción del conector) utilizable para empaquetar un conector API desarrollado por el desarrollador. Como se ha descrito anteriormente, el conector API se puede usar para generar instancias del conector que permiten la interfaz entre el intermediario de servicios en la nube y el ISV de la nube. Como tal, la información de descripción del conector puede incluir cualquier información relacionada con el conector API que se pueda usar para crear una instancia del conector API. Por ejemplo, la información de descripción del conector puede incluir, entre otras cosas, información de UI (por ejemplo, un título del servicio, uno o más iconos, etc.), información del modelo de recursos (por ejemplo, servicio(s) proporcionado(s), tales como espacio en disco, buzones de correo, dominios, etc.), credenciales para establecer el canal de aprovisionamiento, información del plan de servicio (por ejemplo, reglas de facturación para el intermediario/proveedor), información de recursos. La información de descripción del conector se puede almacenar en la base de datos de modelos 302.
Se debe apreciar que el desarrollador puede modificar cualquier porción de la información de descripción del conector (por ejemplo, como puede estar almacenada en la base de datos de modelos 302) a través del portal de UI para desarrolladores 118. Para ello, el portal de UI para desarrolladores 118 está configurado para proporcionar una o más interfaces visuales utilizables por el desarrollador para generar un modelo para el conector y/o publicar el conector (por ejemplo, a través del constructor de conectores 304), ejecutar una o más pruebas en un sistema de pruebas contra el conector desarrollado (por ejemplo, a través del reproductor de conectores 314 y el sistema de pruebas 316), y verificar el conector contra una o más reglas de compatibilidad (por ejemplo, a través del sistema experto 318) para garantizar la compatibilidad con versiones anteriores para actualizaciones/cambios llevados a cabo en un conector.
La base de datos de modelos 302 está configurada para almacenar un modelo para cada conector. El modelo puede incluir cualquier información utilizable para definir o empaquetar el conector, tal como etiquetas de UI (por ejemplo, nombre, descripción, etc.), materiales visuales (por ejemplo, iconos, capturas de pantalla, estilos, etc.), extensiones de UI (por ejemplo, descripciones de cómo conectar elementos de UI en aplicaciones existentes), definiciones de objetos de negocio soportados por el conector (por ejemplo, usuario, buzón, regla de filtrado de spam, etc.). Se debe apreciar que, en algunas realizaciones, al menos una porción de las extensiones de IU se pueden definir como páginas HTML, e incluir JavaScript, CSS, imágenes, etc. relevantes, así como una descripción para conectar los elementos de IU en la estructura de IU para cada página aplicable. Además, la información del modelo puede incluir, para cada objeto soportado por el conector, una o más propiedades (por ejemplo, tipo, descripción, etiqueta, valor por defecto, etc.), una o más relaciones (es decir, cómo el objeto(s) está(n) conectado(s) con otro(s) objeto(s) del modelo de dominio de servicio y la cardinalidad de la(s) relación(es)), y/o mapeo de uso/límite (por ejemplo, cómo el uso/límites están mapeados a recursos y planes vendibles). Se debe apreciar que, en algunas realizaciones, la base de datos de modelos puede mantener múltiples versiones del mismo conector y/o múltiples conectores. En consecuencia, se debe apreciar aún más que, en tales realizaciones en las que se mantienen múltiples versiones, la diferencia entre las versiones (es decir, los cambios) se puede determinar automáticamente (por ejemplo, a través de una comparación de cierta información del modelo).
El constructor de conectores 304 está configurado para generar un archivo de esquema para todos los objetos de negocio asociados con un conector. Para ello, el constructor de conectores 304 está configurado para analizar metadatos (por ejemplo, información de descripción del conector) del conector para identificar los objetos de negocio y generar el archivo de esquema. Además, el constructor de conectores 304 está configurado para generar un conjunto de instrucciones de actualización en aquellas realizaciones en las que el conector no es la primera versión del conector (es decir, el conector que se está empaquetando es una actualización o incluye cambios en un conector previamente empaquetado para el mismo servicio). Las instrucciones de actualización pueden incluir cualquier cambio en el modelo que se pueda rastrear y aplicar a una versión actualizada del conector, tal como cambios en los metadatos del conector, adición de nuevas propiedades en el ámbito del tipo o asignación de un valor predeterminado, eliminación de propiedades, cambio de nombres/tipos de propiedades, adición de servicios (por ejemplo, un nuevo objeto en el modelo de dominio de aplicación), añadir nuevas relaciones a/entre objetos de otro conector o del modelo de dominio de aplicación, cambiar el nombre de las relaciones, cambiar la cardinalidad u opciones de las relaciones, cambiar el tipo requerido por la relación, cambiar las reglas de acceso a propiedades, cambiar las reglas de acceso y/o asignación de relaciones, dividir las relaciones en más de una relación de acuerdo con las reglas, etc.
El constructor de conectores 304 además está configurado para ensamblar el esquema generado anteriormente y las instrucciones de actualización, si procede, junto con el código fuente del conector y las plantillasfront-enden un paquete de conector. Además, el constructor de conectores 304 está configurado para cargar el paquete de conectores ensamblado en la base de datos de servicios disponibles 110 del dispositivo informático de mercado 102 que incluye un catálogo de conectores (es decir, servicios disponibles).
El gestor de bibliotecas 306 está configurado para gestionar el flujo de datos entre las bases de datos ilustrativas, que incluyen ilustrativamente una base de datos de reglas de compatibilidad 308, una base de datos de esqueletos de conectores 310 y una base de datos de plantillasfront-end 312. Paraello, el gestor de bibliotecas 306 está configurado para llevar a cabo operaciones de lectura y escritura en cada una de las bases de datos, así como cualquier otra operación que pueda ser necesario llevar a cabo en los datos (por ejemplo, estandarizar los datos, normalizar los datos, mejorar los datos, etc.).
La base de datos de reglas de compatibilidad 308 está configurada para almacenar reglas para la gestión de versiones (es decir, reglas de compatibilidad). En otras palabras, las normas de compatibilidad garantizan la compatibilidad retrospectiva entre versiones. Por ejemplo, las normas de compatibilidad no permiten modificar el tipo de recursos que se comercializan, dado que se rompería la compatibilidad hacia atrás; sin embargo, las normas de compatibilidad permiten ampliar la configuración de ese tipo de recursos o comercializar tipos de recursos adicionales. Como tal, las reglas de compatibilidad proporcionan la capacidad de permitir que se lleven a cabo actualizaciones automáticas, dado que la actualización propuesta puede ser probada contra las reglas de compatibilidad (por ejemplo, por el constructor de conectores 304). Se debe tener en cuenta que puede haber diversos conjuntos de normas de este tipo. Por ejemplo, una actualización menor puede mantener una compatibilidad total con versiones anteriores, mientras que una actualización mayor puede mantener una compatibilidad limitada con versiones anteriores.
La base de datos del esqueleto de conectores 310 está configurada para almacenar código preparado de acuerdo con el modelo y las mejores prácticas para el desarrollo de conectores. Como tal, el código almacenado se puede usar como un marco de partida para el desarrollo delback-endde un conector. Se debe apreciar que el código se puede personalizar en función del modelo definido por el desarrollador.
La base de datos de plantillasfront-end312 está configurada para almacenar interfaces de usuario para escenarios conocidos (por ejemplo, creación de un nuevo cliente/cuenta, compra de una suscripción para un cliente, desactivación de una suscripción, finalización de una suscripción, etc.). En consecuencia, cuando un desarrollador habilita un escenario conocido, el código de UI relevante para ese escenario se puede añadir a un componente de UI del conector desde la base de datos de plantillasfront-end312.
Se debe apreciar además que, en algunas realizaciones, los datos almacenados en las respectivas bases de datos como se describen en la presente memoria pueden no ser mutuamente excluyentes. En otras palabras, ciertos datos descritos en la presente memoria como almacenados en una base de datos se pueden almacenar adicional o alternativamente en otra base de datos descrita en la presente memoria, o en otra base de datos. Se debe apreciar que, en algunas realizaciones, los datos se pueden almacenar en una única base de datos, una base de datos distribuida, o una disposición de almacenamiento de datos alternativa.
El reproductor de conectores 314 está configurado para ejecutar escenarios de prueba del conector contra un sistema de pruebas (por ejemplo, el sistema de pruebas 316). Dichos escenarios pueden incluir el despliegue del conector, la creación de instancias del conector, la configuración de plantillas y planes de servicio, la prueba de la creación de suscripciones/usuarios, la solicitud de uso de recursos de contador, etc. En consecuencia, el sistema de pruebas 316 está configurado para proporcionar recursos utilizables para probar varios escenarios de un conector. Se debe apreciar que los recursos pueden ser recursos físicos y/o virtuales.
El sistema experto 318 está configurado para analizar servicios de emparejamiento potenciales y sugerir uno o más servicios identificados como candidatos para ser emparejados con el servicio asociado con el conector. Para ello, el sistema experto 318 está configurado para identificar información asociada al conector (por ejemplo, un tipo de servicio, una descripción, etc.) y comparar la información identificada con la información correspondiente de otros servicios que suelen estar emparejados. En un ejemplo ilustrativo, el sistema experto 318 puede sugerir emparejar un servicio anti-spam en base a los resultados del análisis llevado a cabo en un conector para un servicio de correo electrónico. Se debe apreciar que cualquier relación puede cambiar el modelo de conector asociado.
Como se ha descrito anteriormente, el dispositivo informático del portal para desarrolladores 116 puede estar compuesto por uno o más dispositivos informáticos 134. En consecuencia, mientras que el portal de UI para desarrolladores 118, la base de datos de modelos 302, el gestor de bibliotecas 306, el constructor de conectores 304, el reproductor de conectores 314, el sistema de pruebas 316, y el sistema experto 318 se muestran ilustrativamente como residentes en un único dispositivo informático 134 (es decir, el dispositivo informático del portal para desarrolladores 116), se debe apreciar que, en algunas realizaciones, uno o más componentes pueden estar ubicados en diferentes dispositivos informáticos 134, juntos comprenden el dispositivo informático del portal para desarrolladores 116.
Con referencia a continuación a las FIGS. 4A a 4D, se proporciona un procedimiento ilustrativo 400 para crear y distribuir conectores de integración en sistemas de intermediación de servicios en la nube que puede ser llevado a cabo por el dispositivo informático del portal para desarrolladores 116, o más particularmente por uno o más de los componentes del dispositivo informático del portal para desarrolladores 116 (por ejemplo, el portal de UI para desarrolladores 118, el constructor de conectores 304, etc.). El procedimiento 400 comienza en el bloque 402, en el que el dispositivo informático del portal para desarrolladores 116 determina si crear un objeto conector. Si es así, el procedimiento 400 avanza al bloque 404 en el que el dispositivo informático del portal para desarrolladores 116 selecciona un esqueleto de conector relevante (por ejemplo, de la base de datos de esqueletos de conectores 310 de la FIG. 3). Como se ha descrito anteriormente, el esqueleto de conectores puede estar en forma de código utilizable como un marco de partida para el desarrollo delback-endde un conector.
En el bloque 406, el dispositivo informático del portal para desarrolladores 116 genera un identificador único de modelo de conector. En el bloque 408, el dispositivo informático del portal para desarrolladores 116 solicita (por ejemplo, a través del portal de Ul para desarrolladores 118) información de descripción de un modelo de conector a un desarrollador de conectores. En un ejemplo ilustrativo, en el bloque 410, el dispositivo informático del portal para desarrolladores 116 solicita información de U<i>(por ejemplo, un título de servicio, un tipo de servicio, un icono, etc.) y una o más instrucciones de proveedor. Como se ha descrito anteriormente, la información de descripción del conector puede incluir cualquier información relacionada con el conector API que se pueda usar para instanciar una instancia del conector API, tal como información del modelo de recursos (por ejemplo, servicio(s) proporcionado(s), tales como espacio en disco, buzones de correo, dominios, etc.), credenciales para establecer el canal de aprovisionamiento, información del plan de servicio (por ejemplo, reglas de facturación para el intermediario/proveedor), información de recursos.
En el bloque 412, el dispositivo informático del portal para desarrolladores 116 determina si se ha recibido la información solicitada (por ejemplo, a través del portal de desarrollador de UI 118). Si es así, el procedimiento 400 avanza al bloque 414, en el que el dispositivo informático del portal para desarrolladores 116 almacena la información recibida (por ejemplo, en la base de datos de modelos 302 de la FIG. 3). En el bloque 416, el dispositivo informático del portal para desarrolladores 116 notifica a un sistema experto (por ejemplo, el sistema experto 318 de la FIG. 3) llevar a cabo un análisis de versiones (véase, por ejemplo, el procedimiento 500 de la FIG. 5). En otras palabras, el dispositivo informático del portal para desarrolladores 116 notifica al sistema experto que analice los conectores existentes (por ejemplo, en la base de datos de servicios disponibles 110 del concentrador de conectores 106 de la FIG. 1) para posibles conectores que sean versiones anteriores del objeto conector. En el bloque 418, el dispositivo informático del portal para desarrolladores 116 determina si se ha completado el análisis de la versión, tal como se puede determinar al recibir una indicación del sistema experto encargado de llevar a cabo el análisis de la versión.
Si el dispositivo informático del portal para desarrolladores 116 determina que se ha completado el análisis de la versión, el procedimiento 400 avanza al bloque 420, mostrado en la FIG. 4B. En el bloque 420, el dispositivo informático del portal para desarrolladores 116 solicita recibir tipos de recursos del objeto conector del desarrollador del conector (por ejemplo, a través del portal de desarrollador de UI 118) en base al esqueleto de conectores asociado seleccionado por el desarrollador del conector en el bloque 404. En el bloque 422, el dispositivo informático del portal para desarrolladores 116 determina si se han recibido los tipos de recursos solicitados. Si es así, el procedimiento 400 avanza al bloque 424, en el que el dispositivo informático del portal para desarrolladores 116 almacena los tipos de recursos recibidos en la base de datos de modelos (por ejemplo, en la base de datos de modelos 302 de la FIG. 3).
En el bloque 426, el dispositivo informático del portal para desarrolladores 116 notifica al sistema experto (por ejemplo, el sistema experto 318) que lleve a cabo un análisis de relación (véase, por ejemplo, el procedimiento 600 de la FIG. 6). En otras palabras, el dispositivo informático del portal para desarrolladores 116 notifica al sistema experto que analice el objeto conector que se está creando en busca de posibles servicios que relacionar con el servicio del objeto conector. En el bloque 428, el dispositivo informático del portal para desarrolladores 116 determina si se ha completado el análisis de la relación. Si es así, el procedimiento 400 pasa al bloque 430, en el que el dispositivo informático del portal para desarrolladores 116 determina, en base a la información recibida del sistema experto 318 en el bloque 418, si el objeto conector tiene una o más versiones correspondientes del objeto conector que se han publicado anteriormente. Si es así, el procedimiento 400 pasa al bloque 450, que se muestra en la FIG. 4D y se describe más adelante; de lo contrario, el procedimiento 400 pasa al bloque 432, que se muestra en la FIG. 4C.
En el bloque 432, el dispositivo informático del portal para desarrolladores 116 construye un conector en función del modelo de servicio. Para ello, en el bloque 434, el dispositivo informático del portal para desarrolladores 116 recupera el identificador de modelo de conector asociado generado en el bloque 406. Además, en el bloque 436, el dispositivo informático del portal para desarrolladores 116 recupera los recursos de modelo asociados. Además, en el bloque 438, el dispositivo informático del portal para desarrolladores 116 recupera una plantillafront-end(por ejemplo, interfaces de usuario para escenarios conocidos). Más aún, en el bloque 440, el dispositivo informático del portal para desarrolladores 116 diseña un manifiesto basado en los recursos del modelo asociado recuperados y la plantilla delfront-end.
En el bloque 442, el dispositivo informático del portal para desarrolladores 116 determina si el conector se ha construido con éxito. En caso negativo, el procedimiento 400 vuelve al bloque 408 para solicitar información de descripción del conector adicional y/o alternativa; en caso contrario, el procedimiento 400 avanza al bloque 444. En el bloque 444, el dispositivo informático del portal para desarrolladores 116 genera un paquete de conectores basado en el modelo. En el bloque 446, el dispositivo informático del portal para desarrolladores 116 almacena el paquete de conectores (por ejemplo, en la base de datos de servicios disponibles 110 del concentrador de conectores 106 de la FIG. 1). En el bloque 448, el dispositivo informático del portal para desarrolladores 116 transmite una indicación al desarrollador del conector indicando que el paquete del conector fue almacenado.
Como se describió anteriormente, en el bloque 430 (mostrado en la FIG. 4B), si el dispositivo informático del portal para desabolladores 116 determina que el objeto conector tiene alguna versión publicada previamente, el procedimiento 400 pasa al bloque 450, que se muestra en la FIG. 4D. En el bloque 450, el dispositivo informático del portal para desarrolladores 116 construye un conector en función del modelo de servicio. Para ello, en el bloque 452, el dispositivo informático del portal para desarrolladores 116 recupera el identificador de modelo de conector asociado generado en el bloque 406. Además, en el bloque 454, el dispositivo informático del portal para desarrolladores 116 recupera los recursos de modelo asociados. Además, en el bloque 456, el dispositivo informático del portal para desarrolladores 116 comprueba los recursos con respecto a cualquier regla de compatibilidad aplicable para garantizar la compatibilidad con versiones anteriores de las actualizaciones/cambios llevados a cabo en un conector. Como se describió anteriormente, las reglas de compatibilidad proporcionan la capacidad de permitir que se lleven a cabo actualizaciones automáticas, dado que la actualización propuesta se puede probar contra las reglas de compatibilidad (por ejemplo, como se puede almacenar en la base de datos de reglas de compatibilidad 308). Además, en el bloque 458, el dispositivo informático del portal para desarrolladores 116 recupera una plantillafront-end(por ejemplo, interfaces de usuario para escenarios conocidos). Aún más, en el bloque 460, el dispositivo informático del portal para desarrolladores 116 diseña un manifiesto basado en los recursos de modelo asociados recuperados y la plantilla defront-end.
En el bloque 462, el dispositivo informático del portal para desarrolladores 116 determina si el conector se construyó con éxito (por ejemplo, si los recursos violan alguna regla de compatibilidad). En caso negativo, el procedimiento 400 vuelve al bloque 408 para solicitar información de descripción del conector adicional y/o alternativa; en caso contrario, el procedimiento 400 avanza al bloque 464. En el bloque 464, el dispositivo informático del portal para desarrolladores 116 determina cualquier diferencia entre los modelos de la versión anterior del conector y la versión actual del conector. En el bloque 466, el dispositivo informático del portal para desarrolladores 116 genera una o más instrucciones de actualización basadas en las diferencias determinadas en el bloque 464. Como se ha descrito anteriormente, las instrucciones de actualización pueden incluir cualquier cambio de modelo que se pueda rastrear y aplicar a una versión actualizada del conector.
En el bloque 468, el dispositivo informático del portal para desarrolladores 116 genera un paquete de conectores basado en el modelo y las instrucciones de actualización. En el bloque 470, el dispositivo informático del portal para desarrolladores 116 almacena el paquete de conectores (por ejemplo, en la base de datos de servicios disponibles 110 del concentrador de conectores 106 de la FIG. 1). En el bloque 472, el dispositivo informático del portal para desarrolladores 116 transmite una indicación al desarrollador del conector indicando que el paquete del conector fue almacenado.
Con referencia a continuación a la FIG. 5, se proporciona un procedimiento ilustrativo 500 para llevar a cabo un análisis de versión en objetos conectores que puede ser llevado a cabo por el dispositivo informático del portal para desarrolladores 116, o más particularmente por el sistema experto 318 del dispositivo informático del portal para desarrolladores 116. El procedimiento 500 comienza en el bloque 502, en el que el sistema experto 318 determina si se ha recibido una notificación de análisis de versión (por ejemplo, de un desarrollador a través del portal de UI para desarrolladores 118 de las FIGS. 1 y 3).
En el bloque 504, el sistema experto 318 compara la información de descripción del conector del objeto conector actual que se está creando con la información correspondiente del paquete o paquetes de conectores almacenados actualmente en la base de datos de servicios disponibles 110 del concentrador de conectores 106 de la FIG. 1, tal como se puede determinar a partir del modelo asociado (por ejemplo, la información del modelo de recursos almacenada en la base de datos de modelos 302 de la FIG. 3). Como se ha descrito anteriormente, la información de descripción del conector puede incluir cualquier información relacionada con el conector API que se pueda usar para instanciar una instancia del conector API. En un ejemplo ilustrativo, en el bloque 506, el sistema experto 318 compara un tipo de servicio, un nombre de servicio y un icono de servicio de cada objeto conector.
En el bloque 508, el sistema experto 318 determina un nivel de coincidencia entre los objetos conectores como función de un resultado de la comparación llevada a cabo en el bloque 504. En el bloque 510, el sistema experto 318 determina si el nivel de coincidencia determinado en el bloque 508 es mayor o igual que un umbral de nivel de coincidencia. El nivel de coincidencia puede ser cualquier valor numérico (por ejemplo, cantidad, valor de contador, porcentaje, etc.) utilizable para transmitir un nivel de coincidencia entre la información (por ejemplo, el tipo de servicio, el nombre del servicio, el icono del servicio, etc.) de cada objeto conector. En consecuencia, el umbral de nivel de coincidencia se puede definir como cualquier cantidad correspondiente utilizable para comparar con el nivel de coincidencia para determinar si el nivel de coincidencia es lo suficientemente alto como para que se pueda determinar razonablemente que los objetos conectores están asociados (es decir, uno es una versión anterior del otro).
Si el sistema experto 318 determina que el nivel de coincidencia es mayor o igual que el umbral de nivel de coincidencia, el procedimiento 500 se bifurca al bloque 512 antes de avanzar al bloque 514. En el bloque 512, el sistema experto 318 relaciona el objeto conector actual con el conector publicado anteriormente como una nueva versión de dicho objeto conector. Si el sistema experto 318 determina que el nivel de coincidencia es menor que el umbral de nivel de coincidencia, el procedimiento 500 se bifurca al bloque 514, en el que el sistema experto 318 transmite una indicación al constructor de conectores (por ejemplo, el constructor de conectores 304 de la FIG. 3) que indica que el sistema experto ha completado el análisis de la versión. En el bloque 516, el sistema experto 318 transmite un identificador de la versión anterior del objeto conector, de acuerdo con lo que corresponda (es decir, si la relación se produjo en el bloque 512).
Con referencia a continuación a la FIG. 6, se proporciona un procedimiento ilustrativo 600 para llevar a cabo un análisis de emparejamiento en objetos conectores que puede ser llevado a cabo por el dispositivo informático del portal para desarrolladores 116, o más particularmente por el sistema experto 318 del dispositivo informático del portal para desarrolladores 116. El procedimiento 600 comienza en el bloque 602, en el que el sistema experto 318 determina si se ha recibido una notificación de análisis de relación (por ejemplo, de un desarrollador a través del portal de UI para desarrolladores 118 de las FIGS. 1 y 3). En el bloque 604, el sistema experto 318 identifica cualquier otro servicio que pueda estar relacionado con el objeto conector actual. Para ello, en el bloque 606, el sistema experto 318 puede identificar los otros servicios en base a la información de sus paquetes de conectores almacenada en la base de datos de servicios disponibles 110 del concentrador de conectores 106, tales como sus respectivos tipos de recursos de conectores.
En el bloque 608, el sistema experto 318 solicita al desarrollador del conector que acepte la(s) relación(es) identificada(s) con cualquier servicio existente y/o identificado que se vaya a vincular al conector. En el bloque 610, el sistema experto 318 determina si la(s) relación(es) ha(n) sido aceptada(s). Se debe apreciar que, en algunas realizaciones, se pueden aceptar algunas, todas o ninguna de las relaciones identificadas. En algunas realizaciones, puede que no se pida al promotor que acepte las relaciones. En otras palabras, en tales realizaciones, las relaciones se pueden identificar y asociar automáticamente, de forma que el procedimiento 600 avanza directamente del bloque 604 al bloque 612. Si alguna de las relaciones identificadas fue aceptada en el bloque 610, el procedimiento 600 avanza al bloque 612 antes de proceder al bloque 614. En el bloque 612, el sistema experto 318 transmite una indicación a cada uno de los propietarios de conectores asociados con el servicio o servicios aceptados para confirmar la relación. De lo contrario, si alguna de las relaciones identificadas no fue aceptada en el bloque 610, el procedimiento 600 avanza al bloque 614, en el cual el sistema experto 318 transmite una indicación al constructor de conectores (por ejemplo, el constructor de conectores 304 de la FIG. 3) que indica que el sistema experto ha completado el análisis de la relación.
En al menos una realización de la presente divulgación, en la FIG. se muestra un diagrama de flujo de una realización ilustrativa de un procedimiento 700 para integrar aplicaciones en la nube en una plataforma de intermediario de servicios en la nube mediante el uso de un conector universal automatizado. En el bloque 702, el dispositivo informático de mercado 102 transmite una solicitud de creación de suscripción al conector universal 136, y el conector universal 136 responde que se ha recibido una solicitud de suscripción. Si se ha recibido una solicitud de suscripción, el procedimiento 700 pasa al bloque 704; de lo contrario, vuelve al bloque 702.
En al menos una realización de la presente divulgación, el conector universal 136 responde que una suscripción está siendo creada (o procesada dependiendo de la solicitud), y procede al bloque 708 en el que procesa el modelo de recurso recibido. En al menos una realización de la presente divulgación, el controlador universal 170 analiza los contadores y los límites con el intérprete del modelo de recursos 174, en el bloque 710. El procedimiento 700 procede al bloque 712 en el que el controlador de aplicación del conector 172 recibe contadores y límites. A continuación, el procedimiento 700 pasa al bloque 714, en el que el motor de traducción de API 178 procesa los contadores y los límites.
En al menos una realización de la presente divulgación, el procedimiento 700 procede entonces al bloque 716 en el que el controlador universal 170 notifica a la base de datos de CRM 166 que se ha definido un nuevo pedido. En al menos una realización de la presente divulgación, un operador puede revisar la orden, y opcionalmente alterar los datos que pueden ser inválidos, y aprobar o rechazar la orden, en el bloque 718. Tras la aprobación, el procedimiento 700 pasa al bloque 722, en el que se procesan los datos aprobados.
En al menos una realización de la presente divulgación, la aprobación del bloque 718 requiere procesamiento. A modo de ejemplo, un operador puede enviar instrucciones de instalación a través del servidor API de CRM 138, y el dispositivo del conector universal 136, como se muestra en la FIG. 1A. Se apreciará que esta es la instrucción para la activación de la suscripción. Siguiendo con este ejemplo, cualquier modificación de la cuenta se lleva a cabo en el servidor API de CRM 138 y se mantiene en la base de datos 166 (como se muestra en la FIG. 1B), y posteriormente se transmite a través del conector universal 136, al dispositivo informático de intermediario en la nube 130.
En al menos una realización de la presente divulgación, el procedimiento 700 procede al bloque 730 en el que los datos de aprobación se almacenan en la base de datos de suscripción 160. A continuación, el procedimiento 700 pasa al bloque 730, en el que el motor de traducción de API 178 traduce las llamadas del servidor API de CRM 138 a un formato operable por el conector universal 136. Se apreciará que el controlador de aplicación del conector 172 procesa los datos de aprobación y almacena los mismos en la base de datos de suscripción 160. En al menos una realización de la presente divulgación, el controlador de aplicación del conector 172 además formula una respuesta para enviar al motor de sondeo y notificación 176, y eventualmente al dispositivo informático de intermediario del servidor en la nube 130.
En al menos una realización de la presente divulgación, en la FIG. 8 se muestra un diagrama de flujo de una realización ilustrativa de un procedimiento 800 para integrar aplicaciones en la nube en una plataforma de intermediario de servicios en la nube mediante el uso de un paquete de conectores universal automatizado. En el bloque 802, el servidor API de CRM 138 lleva a cabo una comprobación para verificar si se ha recibido un nuevo pedido. Si se recibe un nuevo pedido, el procedimiento 800 pasa al bloque 804, en el que se notifica al operador que se ha recibido el pedido. Se apreciará que el operador puede ser notificado por la operación del navegador 164.
El procedimiento 800 procede al bloque 810. En el bloque 810, se procesan la cuenta, los datos de suscripción y los parámetros. A modo de ejemplo, si una cuenta no existe, se crea la cuenta; si una suscripción no existe, se crea una suscripción. Los datos que acompañan a la creación de dicha cuenta o suscripción se almacenan en la base de datos 166. Se apreciará que el conector universal 136 transmite todos estos datos (por ejemplo, a través de la red 128) a la base de datos 166. A continuación, el procedimiento 800 pasa a la etapa 812, en la que los pedidos filtrados se envían alfront-end(por ejemplo, el navegador 164).
En el bloque 814, el procedimiento 800 comprueba si se han modificado los datos del pedido. Si los datos han sido modificados, el procedimiento 800 procede a la etapa 816, en la que los datos del pedido se almacenan dentro del módulo de auditoría 156. El procedimiento 800 pasa entonces al bloque 818. Alternativamente, si no hay cambios en los datos como se verificó en el bloque 814, el procedimiento 800 procede también al bloque 818. En el bloque 818, se comprueba si se ha recibido la aprobación del pedido. Si se recibe la aprobación del operador, el procedimiento procede al bloque 820; de lo contrario, procede al bloque 824.
A continuación, el procedimiento 800 pasa al bloque 822, en el que se notifica al operador que se ha creado la suscripción.
Si bien la presente divulgación se ha ilustrado y descrito en detalle en los dibujos y en la descripción anterior, la misma se debe considerar como ilustrativa y no de carácter restrictivo, se entiende que sólo se han mostrado y descrito ciertas realizaciones, y que la invención está definida por las reivindicaciones adjuntas.
Claims (19)
1. Un procedimiento para integrar aplicaciones en la nube en una plataforma de intermediario de servicios en la nube (CSB) mediante el uso de un dispositivo del conector universal automatizado (136), el procedimiento comprende:
probar en un dispositivo informático del portal para desarrolladores (116) por medio de un reproductor de conectores (314), un paquete de conectores producido para un software de un dispositivo de proveedor de software independiente;
recibir en un concentrador de conectores (106), el paquete de conectores para un software del dispositivo de vendedor de software independiente;
generar en el concentrador de conectores (106), un par de claves secretas para autenticar un canal de comunicación seguro para una solicitud de suscripción al software entre el CSB y una instancia de conector desplegada por el CSB;
crear la instancia de conector para el paquete de conectores para la integración con la plataforma de CSB, la plataforma de CSB además está configurada para proporcionar licencias para el software;
recibir en un dispositivo informático CSB a través de una interfaz de plataforma de CSB, la solicitud de suscripción para el software, la solicitud de suscripción que comprende una actividad seleccionada de un grupo que consiste en una creación, cambio y eliminación;
transmitir a un dispositivo del conector universal (136) por un controlador de plataforma de CSB, de la solicitud de suscripción;
procesar, en el dispositivo del conector universal (136), la solicitud de suscripción;
notificar a un dispositivo de gestión de relaciones con el cliente (CRM), por medio del dispositivo del conector universal (136), la solicitud de suscripción;
almacenar la solicitud de suscripción en una base de datos de CRM;
obtener la aprobación por parte del dispositivo del conector universal (136), de la solicitud de suscripción; procesar, en el dispositivo del conector universal (136), la solicitud de suscripción, tras recibir una aprobación de la solicitud; y
transmitir un resultado de aprobación de la suscripción a la plataforma de CSB, la plataforma de CSB muestra el resultado de aprobación de la suscripción a un suscriptor.
2. El procedimiento de la reivindicación 1, en el que el paquete de conectores se desarrolla en un portal para<desarrolladores (118), el portal para desarrolladores (>118<) es accesible por el dispositivo de vendedor de software>independiente.
3. El procedimiento de la reivindicación 1, en el que la solicitud de suscripción además comprende un modelo de recurso correspondiente definido en el paquete de conectores.
4. El procedimiento de la reivindicación 3, en el que la solicitud de suscripción es recibida por un controlador de aplicación del conector (172).
5. El procedimiento de la reivindicación 4, que además comprende la etapa de procesar la solicitud de suscripción en un intérprete del modelo de recursos (174).
6. El procedimiento de la reivindicación 1, en el que el procesamiento además comprende la etapa de procesar los datos de la solicitud con un motor de traducción de interfaz de programación de aplicaciones (API) (178).
7. El procedimiento de las reivindicaciones 1 o 3, en el que el procesamiento, en el dispositivo del conector universal (136), además comprende la etapa de analizar los contadores y límites del modelo de recursos del paquete de conectores correspondiente.
8. El procedimiento de la reivindicación 6, en el que el procesamiento además comprende la etapa de procesar contadores y límites con el motor de traducción de la interfaz de programación de aplicaciones (ApI) (178).
9. El procedimiento de la reivindicación 6, en el que la etapa de procesar los datos de la solicitud comprende la etapa de transformar las solicitudes de la plataforma de CSB en un formato operable por el dispositivo de CRM, y además mostrar las solicitudes en una interfaz de usuario (UI) de CRM.
10. El procedimiento de la reivindicación 1 además comprende la etapa en la que el conector universal automatizado (136) transmite una solicitud pendiente al dispositivo de CRM, y sondea una respuesta del operador desde un dispositivo API de CRM.
11. El procedimiento de la reivindicación 1, en el que el procesamiento de los datos de aprobación comprende la etapa de recibir y transformar las instrucciones de instalación para la activación/cambio de suscripción recibidas de un servidor ApI de CRM (138) en un formato visualizable por la UI de la plataforma de CSB.
12. El procedimiento de la reivindicación 1, en el que el procesamiento de una respuesta de CRM además comprende la etapa de transformar las modificaciones de cuenta recibidas de un servidor API de CRM (138) en formato visualizable por una UI de plataforma de CSB.
13. El procedimiento de la reivindicación 1, en el que las modificaciones de la cuenta se almacenan en una base de datos de suscripción (160) operablemente conectada al dispositivo del conector universal (136).
14. El procedimiento de la reivindicación 1, en el que el procesamiento de una respuesta de CRM además comprende la etapa de analizar y hacer coincidir un identificador único de suscripción asociado con un sistema de gestión de suscripciones ISV, el identificador único de suscripción asociado con un sistema de gestión de suscripciones de la plataforma de CSB.
15. El procedimiento de la reivindicación 1 además comprende la etapa de que el dispositivo del conector universal automatizado (136) proporcione una respuesta, la respuesta seleccionada del grupo que consiste en la creación, modificación y eliminación.
16. El procedimiento de la reivindicación 1 además comprende almacenar los datos asociados a la solicitud de suscripción y la respuesta en una base de datos de una región que cumple los requisitos del país en el que opera la plataforma de CSB.
17. El procedimiento de la reivindicación 1 además comprende un módulo de auditoría (156) operablemente conectado con el dispositivo de CRM que registra las acciones del operador en la base de datos de CRM.
18. El procedimiento de la reivindicación 17, en el que los datos de auditoría se usan para analizar problemas técnicos con los componentes de integración.
19. El procedimiento de la reivindicación 1, en el que el dispositivo de CRM además comprende un módulo de seguridad (158) para la autenticación de los conectores universales (136).
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201762578992P | 2017-10-30 | 2017-10-30 | |
| PCT/US2018/058260 WO2019089629A1 (en) | 2017-10-30 | 2018-10-30 | Integrating cloud applications into a cloud service broker platform using an automated, universal connector package |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2960508T3 true ES2960508T3 (es) | 2024-03-05 |
Family
ID=66245730
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18873780T Active ES2960508T3 (es) | 2017-10-30 | 2018-10-30 | Integración de aplicaciones en la nube en una plataforma de intermediación de servicios en la nube por medio de un paquete de conector universal automatizado |
Country Status (18)
| Country | Link |
|---|---|
| US (1) | US11019168B2 (es) |
| EP (1) | EP3704834B1 (es) |
| JP (1) | JP7097958B2 (es) |
| CN (1) | CN111357241B (es) |
| AU (1) | AU2018357874B2 (es) |
| CA (1) | CA3079948C (es) |
| DK (1) | DK3704834T3 (es) |
| ES (1) | ES2960508T3 (es) |
| FI (1) | FI3704834T3 (es) |
| HR (1) | HRP20231287T1 (es) |
| HU (1) | HUE065021T2 (es) |
| LT (1) | LT3704834T (es) |
| MX (1) | MX2020004210A (es) |
| PL (1) | PL3704834T3 (es) |
| PT (1) | PT3704834T (es) |
| RS (1) | RS64719B1 (es) |
| SI (1) | SI3704834T1 (es) |
| WO (1) | WO2019089629A1 (es) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11064013B2 (en) * | 2018-05-22 | 2021-07-13 | Netskope, Inc. | Data loss prevention using category-directed parsers |
| US11023359B2 (en) * | 2019-01-18 | 2021-06-01 | Kleeen Software, Inc. | Automated API generation |
| US11275625B2 (en) * | 2019-01-18 | 2022-03-15 | Kleeen Software, Inc. | System and method for automated application programming interface generation |
| US10999393B2 (en) * | 2019-03-06 | 2021-05-04 | Dell Products L.P. | Cloud broker for connecting with enterprise applications |
| US11102227B2 (en) * | 2019-04-12 | 2021-08-24 | EMC IP Holding Company LLC | Ecosystem-aware smart arrays for unified analytics and troubleshooting |
| WO2021051013A1 (en) * | 2019-09-12 | 2021-03-18 | Kleeen Software, Inc. | Automated api generation |
| US11947681B2 (en) | 2020-10-02 | 2024-04-02 | Blockframe, Inc. | Cryptographic secret generation and provisioning |
| US11503038B1 (en) | 2021-10-27 | 2022-11-15 | Netskope, Inc. | Policy enforcement and visibility for IaaS and SaaS open APIs |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7633955B1 (en) * | 2004-02-13 | 2009-12-15 | Habanero Holdings, Inc. | SCSI transport for fabric-backplane enterprise servers |
| US8228812B2 (en) * | 2008-12-12 | 2012-07-24 | Electronics And Telecommunications Research Institute | Method and system for providing multicast service in next-generation network |
| CN102255933B (zh) * | 2010-05-20 | 2016-03-30 | 中兴通讯股份有限公司 | 云服务中介、云计算方法及云系统 |
| US8699499B2 (en) * | 2010-12-08 | 2014-04-15 | At&T Intellectual Property I, L.P. | Methods and apparatus to provision cloud computing network elements |
| US10129211B2 (en) * | 2011-09-15 | 2018-11-13 | Stephan HEATH | Methods and/or systems for an online and/or mobile privacy and/or security encryption technologies used in cloud computing with the combination of data mining and/or encryption of user's personal data and/or location data for marketing of internet posted promotions, social messaging or offers using multiple devices, browsers, operating systems, networks, fiber optic communications, multichannel platforms |
| WO2013158908A1 (en) * | 2012-04-18 | 2013-10-24 | Mastercard International Incorporated | Systems and methods for managing transactions for a merchant |
| CN102769628B (zh) * | 2012-07-27 | 2014-03-26 | 腾讯科技（深圳）有限公司 | 页面登录方法及服务器 |
| US9621435B2 (en) * | 2012-09-07 | 2017-04-11 | Oracle International Corporation | Declarative and extensible model for provisioning of cloud based services |
| US10148530B2 (en) * | 2012-09-07 | 2018-12-04 | Oracle International Corporation | Rule based subscription cloning |
| US20150156065A1 (en) * | 2013-03-15 | 2015-06-04 | Gravitant, Inc. | Policy management functionality within a cloud service brokerage platform |
| US9832205B2 (en) * | 2013-03-15 | 2017-11-28 | International Business Machines Corporation | Cross provider security management functionality within a cloud service brokerage platform |
| US20150067171A1 (en) * | 2013-08-30 | 2015-03-05 | Verizon Patent And Licensing Inc. | Cloud service brokering systems and methods |
| US9749224B2 (en) * | 2014-03-31 | 2017-08-29 | Verizon Patent And Licensing Inc. | Method and apparatus for cloud provisioning of communication services |
| US9733849B2 (en) * | 2014-11-21 | 2017-08-15 | Security First Corp. | Gateway for cloud-based secure storage |
| US20160260157A1 (en) * | 2015-03-05 | 2016-09-08 | International Business Machines Corporation | Rapid service orchestration and management |
| US10701137B2 (en) * | 2016-09-30 | 2020-06-30 | Micro Focus Llc | Exchange service management contents with a cloud entity via a self-contained cloud content package |
| US10564959B2 (en) * | 2017-03-14 | 2020-02-18 | Google Llc | Shared software libraries for computing devices |
| KR102263366B1 (ko) * | 2017-06-15 | 2021-06-11 | 한국전자통신연구원 | 다중 클라우드 기반의 클라우드 브로커리지를 이용한 클라우드 서비스 제공 장치 및 그 방법 |
| US10942719B2 (en) * | 2018-05-15 | 2021-03-09 | Ingram Micro Inc. | System and method for connector development and integration channel development |
-
2018
- 2018-10-30 RS RS20230925A patent/RS64719B1/sr unknown
- 2018-10-30 PL PL18873780.3T patent/PL3704834T3/pl unknown
- 2018-10-30 FI FIEP18873780.3T patent/FI3704834T3/fi active
- 2018-10-30 PT PT188737803T patent/PT3704834T/pt unknown
- 2018-10-30 DK DK18873780.3T patent/DK3704834T3/da active
- 2018-10-30 EP EP18873780.3A patent/EP3704834B1/en active Active
- 2018-10-30 US US16/175,502 patent/US11019168B2/en active Active
- 2018-10-30 CA CA3079948A patent/CA3079948C/en active Active
- 2018-10-30 HU HUE18873780A patent/HUE065021T2/hu unknown
- 2018-10-30 AU AU2018357874A patent/AU2018357874B2/en active Active
- 2018-10-30 CN CN201880070962.0A patent/CN111357241B/zh active Active
- 2018-10-30 LT LTEPPCT/US2018/058260T patent/LT3704834T/lt unknown
- 2018-10-30 JP JP2020522825A patent/JP7097958B2/ja active Active
- 2018-10-30 MX MX2020004210A patent/MX2020004210A/es unknown
- 2018-10-30 HR HRP20231287TT patent/HRP20231287T1/hr unknown
- 2018-10-30 WO PCT/US2018/058260 patent/WO2019089629A1/en active Application Filing
- 2018-10-30 SI SI201830993T patent/SI3704834T1/sl unknown
- 2018-10-30 ES ES18873780T patent/ES2960508T3/es active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CA3079948C (en) | 2022-12-20 |
| AU2018357874B2 (en) | 2022-12-01 |
| MX2020004210A (es) | 2020-08-13 |
| CN111357241A (zh) | 2020-06-30 |
| DK3704834T3 (da) | 2023-09-25 |
| RS64719B1 (sr) | 2023-11-30 |
| US20190132410A1 (en) | 2019-05-02 |
| HRP20231287T1 (hr) | 2024-02-02 |
| CN111357241B (zh) | 2023-07-21 |
| HUE065021T2 (hu) | 2024-04-28 |
| SI3704834T1 (sl) | 2023-12-29 |
| JP2021503118A (ja) | 2021-02-04 |
| CA3079948A1 (en) | 2019-05-09 |
| JP7097958B2 (ja) | 2022-07-08 |
| EP3704834A1 (en) | 2020-09-09 |
| PL3704834T3 (pl) | 2023-12-27 |
| EP3704834B1 (en) | 2023-07-19 |
| PT3704834T (pt) | 2023-09-26 |
| US11019168B2 (en) | 2021-05-25 |
| LT3704834T (lt) | 2023-09-25 |
| AU2018357874A1 (en) | 2020-04-23 |
| WO2019089629A1 (en) | 2019-05-09 |
| FI3704834T3 (fi) | 2023-10-06 |
| EP3704834A4 (en) | 2021-08-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2960508T3 (es) | Integración de aplicaciones en la nube en una plataforma de intermediación de servicios en la nube por medio de un paquete de conector universal automatizado | |
| US11132241B2 (en) | API registry in a container platform for automatically generating client code libraries | |
| US20220385663A1 (en) | Self-serve appliances for cloud services platform | |
| US20190073216A1 (en) | Customized static source code analysis | |
| JP7105298B2 (ja) | クラウドサービスブローカーシステムにおいてオファーの機能を自動的に検証する技術 | |
| CN110808855B (zh) | 互联网技术架构及管理方法、装置、电子设备和介质 | |
| US11748079B2 (en) | Technologies for creating and distributing integration connectors in a cloud service brokerage system | |
| CN113535574B (zh) | 一种测试用户数据的自动生成方法、装置、设备和介质 | |
| CN110795137A (zh) | 权限配置方法、装置、系统、电子设备及可读介质 | |
| CN108737474B (zh) | Http接口调用的方法、装置 | |
| US20220300611A1 (en) | Run-time communications protocol parameter adjustment in containerized applications | |
| Chondamrongkul | Model-driven framework to support evolution of mobile applications in multi-cloud environments | |
| Kurniawan et al. | Practical Azure Functions | |
| Granlund et al. | RFC: A user-friendly system for managing and automating network changes in a secure zone model | |
| Dissanayake | REST API Service Middleware | |
| Jayakody | Quota: wi-fi data managing and costing system | |
| Wiggers | BizTalk Server 2010 Cookbook |