Mashup

En la actualidad, Pega Platform™ es compatible con la UX de negocio a consumidor (B2C) a través de una interfaz de mashup. Es posible que la forma en que se dibujan las pantallas de mashup cambie en lanzamientos posteriores. Actualmente, las pantallas de mashup solo son compatibles con el uso de los arneses y las secciones de Theme Cosmos. En lanzamientos posteriores, se incluirá una nueva interfaz de canal que es similar a un mashup basado en Cosmos React.

Un mashup también puede usarse para el negocio con los empleados (B2E). Supongamos que un empleado de una empresa usa Salesforce. Es posible ampliar Salesforce para aprovechar otras aplicaciones, incluidas las creadas con Pega Customer Decision Hub™ que usan la interfaz actual de Pega Mashup (la aplicación usará la interfaz de Cosmos React en un lanzamiento posterior).

Un mashup es compatible con varios tipos de acciones. Un cliente no es un trabajador del caso. Las acciones, como Get Next Work y Open assignment, no se aplican porque la página OperatorID pertenece al operador de modelo anónimo. Ese operador nunca es propietario de las asignaciones de la lista de trabajo porque las asignaciones son visibles para todos los usuarios del mashup. Una sección de la página UI embebida con un layout de tabla puede proporcionar acceso de solo lectura a un caso que está en pausa en una asignación de la cesta de trabajo.

Para B2C, las dos acciones de mashup más adecuadas son Create a case y Display a page.

Con la acción Create a case, los clientes introducen datos en la etapa de creación donde no existe ninguna asignación. La etapa de creación es similar a Display a page en el sentido de que la pantalla se muestra contra un arnés aplicado a Data-Portal. En lanzamientos anteriores a la versión 8.5 de Pega Platform, los usuarios deben desarrollar un arnés nuevo y declarar el tipo de caso como temporal dentro de la pestaña Settings (Configuración) de la regla de tipo de caso.

Para la Display a page acción , se puede definir un arnés contra cualquier clase de datos. Una clase de datos que parece conveniente usar extiende PegaData-Contact. Dicha clase de datos puede extenderse para agregar -SelfService. Las instancias de la clase de datos PegaData-Contact-extending se conservan como datos de referencia concretos. La extensión  -SelfService de esa clase es abstracta, lo que significa que la extensión nunca se conserva.

Los datos pueden conservarse fuera de un BLOB de caso independientemente de Create a case y Display a page que se use. Un desarrollador puede definir una actividad SavePlan que invoque el método Save-DataPage para cualquier clase de datos. Cualquier clase de datos puede hacer referencia a un caso mediante la clave pyID del caso.

El problema de identificar de forma única quién es un cliente surge con la acción Create a case  o Display a page . De lo contrario, la interfaz de mashup no es más que el envío de un formulario que contiene la información de contacto de una persona: un uso único de la interfaz de mashup. Poder identificar quién es el cliente repetidamente (sin que tenga que volver a introducir su información de contacto) es un reto, pero es factible.

La implementación de un mashup es mucho más que el diseño de pantallas adecuadas para su visualización por parte de personas de contacto externo que no son empleados, como los clientes. La seguridad es una preocupación principal. Hacer que una aplicación sea accesible al público aumenta el número de usuarios potenciales (incluidos los hackers) de forma considerable.

Una interfaz de mashup le permite acceder a cualquier persona que tenga un enlace a una aplicación. La mejor manera de acceder es usando un servicio de autenticación anónimo restringido por persona.

Cuando el servicio de autenticación anónimo se asocia con una interfaz de mashup, el operador del modelo del lado del servidor puede modificarse según sea necesario. Cuando un contacto externo (como un cliente) usa por primera vez una interfaz de mashup, la identidad única del usuario es desconocida. El usuario debe enviar primero un formulario que contenga su información de contacto, como nombre, número de teléfono y dirección de correo electrónico.

La identificación única podría ser tan simple como que los usuarios introduzcan el Id. único secreto que recibieron en respuesta a una solicitud de registro. En dicha situación, el usuario es responsable de mantener oculto ese Id. único. A efectos prácticos, este tipo de Id. único es un GUID.

Como alternativa, se les puede solicitar a los usuarios que proporcionen un nombre de usuario y una contraseña al registrarse. El sistema valida si el nombre de usuario es único (lo cual es un requerimiento) antes de continuar. Si no es posible la validación de la exclusividad del nombre de usuario, el usuario debe proporcionar un nombre de usuario diferente.

En el futuro, cuando los usuarios accedan al sistema, deberán empezar por proporcionar un dato único, ya sea su GUID o su nombre de usuario. Si se proporciona un nombre de usuario, el sistema también pide una contraseña. La contraseña se puede validar usando la función @samepassword().

No hay nada que impida el uso de formas de identificación más seguras, como la autenticación de dos factores (2FA) o la contraseña de un solo uso (OTP). Para obtener más información, consulte Autenticación de múltiples factores con una contraseña de un solo uso.

Cuando usa la interfaz de mashup Create a case (Crear un caso) que se obtiene de un servicio de autenticación anónimo y quiere que el usuario se identifique de forma única, la etapa de creación debe comenzar ejecutando un procedimiento de inicio de sesión de identificación única para continuar. Por el contrario, cuando un trabajador del caso (como un representante de servicio al cliente o un miembro del equipo de ventas) crea el caso, la primera pantalla que se muestra es una sección de búsqueda de contactos que se autocompleta.

Independientemente de quién complete la sección de identificación del contacto (el propio contacto o un trabajador del caso), el contacto se identifica de forma exclusiva si es correcto al enviarlo.

A partir de ese momento, el caso establece una propiedad que hace referencia al contacto previamente registrado o registrado sobre la marcha. Cuando el contacto es un cliente, la propiedad que se establece puede denominarse CustomerGUID , y lo mismo sucede para otros roles de persona de contacto.

Una clase de datos que es más conveniente usar para B2C junto con la opción Display a page (Mostrar una página) de mashup es una que, en última instancia, extiende PegaData-Contact, que a su vez extiende Data-Party-Person. Tenga en cuenta que, para el modelo de negocio a negocio (B2B), la clase raíz es PegaData-Organization.

Para un contacto de persona, el nombre de clase más genérico que se puede usar es ORG-APP-Contact. Si hay una razón para especializar la clase que se basa en el rol del contacto, se pueden definir clases de datos, como ORG-APP-Member u ORG-APP-Customer que extienden ORG-APP-Contact. 

Una clase concreta ORG-APP-Contact puede extenderse usando la herencia de patrón, para definir una clase abstracta usada específicamente para el acceso externo de autoservicio. El nombre de la clase abstracta sería ORG-APP-Contact-SelfService. Esa clase abstracta tiene una propiedad TrueFalse llamada Authenticated. Esa propiedad nunca se conserva, ya que se aplica a la sesión del usuario, que es transitoria. El valor de Authenticated se configura en true (verdadero) después de que el usuario se identifica correctamente.

Un caso puede ser específico de un contacto externo, o varios contactos externos pueden hacer referencia a un caso.  La primera es una relación personalizada (1:1). La segunda es una relación grupal (M:1).

Un ejemplo de escenario personalizado es cuando un ejecutivo de ventas crea un caso que se dirige a un cliente específico.

Un escenario grupal es un caso de seminario web en el que usuarios externos solicitan asistir a ese seminario web. La clase de datos en la que se muestra la interfaz de mashup necesitaría una propiedad CaseRef. Por ejemplo, la clase de datos es ORG-Data-WebinarRegistration. 

Una posible continuación del escenario de ejecutivo de ventas personalizado implica que el cliente se identifique de forma única con la acción Display a page de un mashup, después de lo cual se muestra una lista de casos donde la propiedad CustomerGUID de cada caso coincide con el GUID del cliente.

El acceso al caso preexistente por parte de un contacto externo debe restringirse para la Persona cliente, miembro o inscrito. 

Supongamos que un caso se pone en pausa en una asignación de cola de trabajo propiedad del Departamento de Ventas inmediatamente después de que este haya aprobado una cotización. El hecho de que el Departamento de Ventas haya creado el caso o que el cliente haya usado el autoservicio es irrelevante. El propósito de la pausa es que el cliente revise la cotización aprobada. El cliente puede aprobar o rechazar esa propuesta a través de un mashup, no en relación con el caso en sí, sino a través de una instancia de datos especialmente creada que hace referencia tanto al cliente como al caso.

El Departamento de Ventas puede observar cuando se produce la aprobación a través de su portal de ventas personalizado. El miembro del Departamento de Ventas puede continuar manualmente el caso si el cliente lo acepta o esperar a que un programador de trabajos haga avanzar el caso. Se debe evitar el acceso posterior al caso por parte del cliente a partir de ese momento. El cliente solo tiene acceso a las dos primeras etapas: de creación y cotización. Además, el cliente no puede acceder a ningún otro tipo de caso.

Se puede aplicar una seguridad más compleja, pero es más difícil. Con la seguridad de autorización regular, las propiedades dentro de la página OperatorID (pyUserIdentifier especialmente) pueden compararse con una propiedad dentro de una asignación, un caso o una instancia de datos. Se debe usar una página diferente con mashup porque la página OperatorID está dirigida al operador del modelo.

Cuando se usa la acción Display a page, el nombre de esa página alternativa del portapapeles es pyDisplayHarness. Cuando se usa la acción Create a case, el nombre de esa página alternativa del portapapeles es D_ContactSelfServiceEditable.

Como suele ocurrir cuando se usa Pega Platform, hay diversas formas de implementar la misma funcionalidad. Para el mashup, puede usar la plantilla de circunstancias pyIsMashup o realizar la puesta en circunstancia usando una propiedad, como pyCreatedByChannel, que es sinónimo de pyIsMashup. También puede definir secciones que embeban otras secciones; la visibilidad de esas secciones embebidas se basa en un privilegio concedido a la Persona.

De esta manera, la sección principal tiene dos secciones embebidas; una de ellas solo visible para la Persona del Departamento de Ventas. Esa sección visible solo para el Departamento de Ventas muestra los costos y las ganancias. La segunda sección es visible para la Persona cliente. La visibilidad de la sección embebida se puede controlar usando el checkbox Associated privileges  cuando se agrega la sección a otra sección.

Las reglas de tipo de caso solo pueden ponerse en circunstancia usando una propiedad de tipo Texto, no una plantilla de circunstancias. En el data transform pyDefault del caso, la propiedad lista para usar (OOTB) pyCreatedByChannel  es igual a un valor como "Mashup" cuando pxThread.isWebMashup = true.. Una regla de decisión reutilizable llamada ChannelIsMashup puede encapsular esa condición booleana.

Poner en circunstancia la regla de tipo de caso mejora el mantenimiento porque el Case Designer (Diseñador de caso) muestra claramente que la regla de tipo de caso se puso en circunstancia. El tipo de caso circunstanciado no necesita mostrar todas las etapas que tiene el caso base. De hecho, resulta mejor para un trabajador que no sea del caso que solo vea las dos primeras etapas. Al final de la segunda etapa y después de esta, la propiedad de circunstancia, por ejemplo pyCreatedByChannel , puede eliminarse. Esto se logra mediante un disparador de declaración, así como una figura de utilidad que llama a la actividad del disparador de declaración. Una vez que se elimina la propiedad de circunstancia, el comportamiento del tipo de caso vuelve a la definición de la regla base de las etapas que siguen a las dos primeras etapas.

La plantilla de circunstancia pyIsMashup es útil cuando se aplica a la sección pyCaseMainInner. La plantilla del panel principal del caso móvil se puede usar para la sección circunstanciada. Toda sección que no esté incluida en esa plantilla puede eliminarse. La única pista de que se trata de un caso es la sección pxDisplayStages que se muestra.  Como la circunstancia de tipo de caso solo tiene dos etapas, la UX no plantea preguntas sobre lo que ocurre más allá de esas dos etapas iniciales. La plantilla de circunstancia pyIsMashup puede usarse también para otras reglas que no sean secciones, como los data transforms. 

La desventaja de usar la plantilla de circunstancia pyIsMashup para secciones de aplicaciones de nivel superior es que esas secciones no se pueden editar en App Studio porque pxThread.isWebMashup = false. Lo que se puede hacer es estructurar una sección circunstanciada y después, dentro de ella, embeber una sección no circunstanciada. A la sección embebida se le da un nombre que no deje dudas de que está destinada a los usuarios del mashup.

El problema con este enfoque es cómo saben los usuarios de App Studio que esa vista existe cuando el Case Designer (Diseñador de casos) no la muestra.  El usuario de App Studio necesita saber que debe mirar la pestaña Views (Vistas) de los casos y el nombre de la sección.

El uso del enfoque  Associated privileges resuelve este problema de forma más clara. Un desarrollador en App Studio puede recibir el privilegio de ver lo que la Persona cliente ve. Al mismo tiempo, el desarrollador en App Studio ve lo que la Persona empleado (por ejemplo, el Departamento de Ventas) ve. La Persona del Departamento de Ventas y la Persona cliente solo ven una de las dos secciones, no las dos.

Una página web que embebe una interfaz de mashup no necesita recuperarse de un servidor web para probar la interfaz de mashup. La misma página web puede mostrarse haciendo clic en un archivo HTML de la página web. La comunicación con Pega Platform se produce desde la página web.  La ubicación en la página web en la que esto ocurre es un elemento de script con un atributo src. El valor del atributo src es una URL de Pega Platform generada por la página de configuración de la interfaz de mashup.

La acción Display a page puede simularse en un caso definido en una aplicación DevOnly construida sobre la aplicación de producción. El caso simplemente declara una página embebida que tiene la misma clase de datos que el arnés de mashup. El caso tiene una única asignación de circuito cerrado. En esa asignación, la acción de flujo de circuito cerrado muestra una sección que se obtiene de la página embebida. Esa sección es la misma que muestra el arnés de mashup.

Debido a la puesta en circunstancia, es más difícil simular la acción Create a case de mashup dentro de una interfaz de portal. La misma regla no puede ponerse en circunstancia de dos maneras diferentes. Si se usa el enfoque Associated privileges (Privilegios asociados), se minimiza la necesidad de simular la acción Create a case (Crear un caso). Conseguir que la sección pyCaseMainInner se muestre de la forma en que un usuario del mashup ve la sección es difícil. Es posible que sea un problema usar una omisión de ruleset para permitirle a una versión circunstanciada del data transform anular la versión base en un ruleset diferente.