Implementación de las interfaces de mashup de B2C

Se pueden usar las mismas reglas para identificar de forma única un contacto, ya sea usando la acción de mashup Create a case o la acción deDisplay a page mashup. La única cuestión es si aplicar el código de identificación del contacto asociado con el mashup a la clase concreta FSG-Data-Contact o definir una nueva clase abstracta -SelfService en un nuevo ruleset, esa clase heredera de patrones FSG-Data-Contact.

Desarrollar una forma común, a nivel de la empresa, para que los contactos aprueben los casos creados en una aplicación de nivel superior es un reto, pero no imposible. Tenga en cuenta como la página de datos D_pxCaseDetail puede cambiar la clase de Work- al nombre de la clase que se proporciona a su parámetro CaseClass . Pero, ¿cómo se puede mostrar una sección que se obtiene de D_pxCaseDetail? Y, ¿cómo se obtienen los valores proporcionados al parámetro D_pxCaseDetail's CaseClass y CaseID específicos para el contacto identificado de forma única?

Existen dos maneras de mostrar una sección de forma dinámica:

1. Incruste una sección en el nivel de la empresa de Work-  y luego haga que la aplicación de nivel superior anule dicha sección por su nombre dentro de una clase de tipo de caso.
2. Como se demostró en la sección Work- pyApproval sin plantilla, use .pyApprovalSectionName para asignar un nombre a la sección embebida de forma dinámica.

Opción 1: Clase y ruleset nuevos o existentes

La extensión del nombre de la clase -SelfService es relevante porque puede ser abstracta. Es conveniente agregar una propiedad Authenticated TrueFalse a esa clase abstracta -SelfService, no a la FSG-Data-Contact, ya que el valor de la propiedad Authenticated solo puede ser verdadero cuando está en línea. En la pestaña Advanced de una regla de propiedad, es posible seleccionar el checkbox Do not save property data, lo que significa que es posible aplicar la propiedad Authenticated a FSG-Data-Contact y no hacerla persistente. Aun así, por razones de mantenimiento, las propiedades deben aplicarse a una clase sinónimo con el propósito de su existencia. Crear la clase FSG-Data-Contact-SelfService en un ruleset por separado también tiene ventajas. Si quiere localizar las reglas que se usan para el autoservicio de contactos, busque en el ruleset ContactSelfService.

Puede ser difícil hacer que una clase concreta se extienda por una clase abstracta. La clase FSG-Data-Contact-SelfService puede conservar los datos en FSG-Data-Contact simplemente ejecutando la actividad SavePlan de FSG-Data-Contact. Las propiedades que se definen en FSG-Data-Contact-SelfService son desconocidas para FSG-Data-Contact,, por lo que dichas propiedades nunca se conservan.

¿Qué pasa a la inversa? La clase FSG-Data-Contact-SelfService recibe el pyGUID de un contacto. La clase SelfService puede ciertamente usar la página de datos D_Contact que proviene de una búsqueda en la base de datos, pero ¿cómo puede la clase SelfService absorber las propiedades de la instancia del contacto sin tener que establecer cada propiedad una por una? La clase SelfService  quiere dejar el valor de su propiedad pxObjClass como está.

Una solución es aprovechar el método Page-Merge-Into en una actividad. En el primer paso, la pxObjClass de la página principal se establece en param.ObjClassNew. El segundo paso es Page-Merge-Into. El tercer paso, Page-Change-Class, se usa para restaurar el valor pxObjClass de la página principal.

Opción 2: Visualización dinámica de la sección del caso

Las secciones con plantillas no son compatibles con propiedades como pyApprovalSectionName para representar dinámicamente una sección embebida por su nombre. La única opción es usar un nombre de sección incrustada genérico, como ContactSelfServiceApproval.

Tener que usar una sección incrustada con un nombre específico limita el diseño del mashup de autoservicio para permitir solo un tipo de aprobación para cada tipo de caso, pero ¿es eso realmente una limitación? No es realista que un cliente tenga que aprobar o rechazar decisiones en varias etapas del tipo de caso. La necesidad actual de FSG es proporcionar un autoservicio hasta la etapa de cotización del caso BookEvent. Más allá de la etapa de cotización, entran en juego otras personas de FSG, como los ejecutivos y los gerentes de eventos. El cliente no necesita participar en dichas etapas.

Opción 3: Fuente de información CaseClass y CaseID, y cómo se limita al contacto

Supongamos que un caso asociado con un contacto externo quiere que ese contacto lo revise. El caso necesita una manera de conservar esta intención de revisión de manera que le permita al contacto descubrir dicha intención. No es posible que el nivel de la empresa sepa cuáles son esos tipos de caso. Se puede codificar una solución única para cada interfaz de mashup específica del caso, pero esa no es la forma correcta de desarrollar el software.

La mejor manera de que un caso se anuncie a sí mismo a un contacto al que se le solicita una revisión es definir una clase de datos a nivel de la empresa. En la aplicación de FSG, se agrega una clase FSG-Data-ContactIssuedApproval al ruleset ContactSelfService. Las propiedades de esta clase son las siguientes: ApprovalType, Approved, CaseClass, CaseRef, ContactRef, LinkText y WaitingForContactInput. Un caso completa y conserva una instancia de esta clase, luego espera en una asignación de cola de trabajo para que el contacto revise el caso. El contacto puede cambiar Approved a true (verdadero), o enviarlo dejando el valor como false (falso). En este caso, false (falso) indica Rejected. Al enviar la decisión Approve (Aprobado) o Reject (Rechazado) del contacto, la propiedad WaitingForContactInput, que inicialmente se estableció en true (verdadero), se establece en false (falso). 

Dentro de una interfaz de mashup Display a page (Mostrar una página), un contacto identificado puede ver una lista de instancias FSG-Data-ContactIssuedApproval donde la propiedad ContactRef es igual al GUID del contacto y WaitingForContactInput es igual a true (verdadero). Una página de datos D_CaseDetail usa los valores CaseClass y CaseRef para establecer el contexto adecuado para mostrar la anulación de la sección ContactSelfServiceApproval del caso BookEvent de la sección Work- ContactSelfServiceApproval incrustada definida a nivel de la empresa. LinkText es una breve descripción de lo que es la aprobación. No es necesario usar un control de enlace. El layout de tabla que muestra las instancias ContactIssuedApproval puede configurarse en cambio para el funcionamiento Master/Detail (Principal/Detalle). Cuando se hace clic en una fila, se abre un cuadro de diálogo modal.

Directorio FSGSample

El archivo FSGSample.zip se descarga de una regla Rule-File-Binary como se muestra a continuación.

El archivo FSGSample.zip puede extraerse en un directorio ../tomcat/webapps y luego se puede acceder a este usando <span> the  the  </span><cite>http://:/FSGSample/</cite>. Se iniciará muy rápidamente una edición de Pega Platform™ Personal, con la aplicación web prweb eliminada. Se puede crear un marcador llamado "FSG Sample" para capturar la url de la aplicación web.

Sin embargo, no es necesario hacerlo. Los archivos HTML del directorio PASample descomprimido pueden abrirse directamente. El archivo index.html se abre primero cuando se accede a este desde un servidor web, como Tomcat. Sin embargo, puede hacer clic directamente en case1.html y case2.html .

La vista de configuración de la interfaz de mashup en Dev Studio o App Studio generó el código de mashup en los archivos case1.html y case2.html. La URL del servicio de autenticación anónimo BookingEventCustomer se copia en el campo URL antes de hacer clic en el botón Generate Mashup code (Generar código de mashup). Puede y debe cambiar la información de : entre https:// y /prweb/PRAuth/BookingEventSelfService para que se dirija al servidor donde está instalada la aplicación de reservas.

El archivo de imagen en segundo plano, bg.png, se encuentra en el directorio FSGSample/images.

Cómo funciona la aprobación emitida por contactos

Inicie sesión en la aplicación de FSG. Tenga en cuenta la sección Approvals de FSG-Data-Contact-SelfService, que se muestra como una pestaña en la sección RegisterContact .

La sección Approvals  embebe la sección PendingApprovals sin plantillas. La sección PendingApprovals  cuenta con un layout de tabla que muestra una lista de instancias FSG-Data-ContactIssuedApproval . La página de datos de la lista D_PendingApprovalList pasa su parámetro ContactGUID a través de la definición de reportes PendingApprovals, que filtra las filas FSG-Data-ContactIssuedApproval por ContactRef = param.ContactGUID y WaitingForContactInput = true.

El layout de tabla de la sección PendingApprovals se configura para un operador Master/Detail (Principal/Detalle). Al hacer clic en una fila que muestra el valor de la propiedad LinkText, se muestra una acción de flujo ShowWaitingApproval en un cuadro de diálogo. En la parte superior de la sección ShowWaitingApproval, se encuentra una sección embebida denominada ContactSelfServiceApproval. La sección embebida se obtiene de D_CaseDetail[pyID:.CaseRef,CaseClass:.CaseClass].

En la parte inferior de la sección ShowWaitingApproval, se encuentra una sección embebida denominada ApprovalButtons. El botón Approve (Aprobar) ejecuta el data transform EnterDecision, pasando Approve  como el valor del parámetro de decisión. El botón Reject (Rechazar) pasa Reject a la misma transformación.

El data transform EnterDecision establece de manera correcta el valor de la propiedad Approved de acuerdo con el valor del parámetro de decisión, y luego establece WaitingForContactInput en false.

Por último, el data transform EnterDecision ejecuta la actividad SavePlan que se define en la clase FSG-Data-ContactIssuedApproval , seguido de un commit.

Interfaz de mashup de autoservicio de cotización de la aplicación de reservas

La capacidad de autoservicio de cotizaciones se implementa por completo en el nivel de la aplicación de reservas, con excepción del proceso de registro e identificación única del cliente.

A primera vista, parece que solo el proceso de varios pasos de Cotización pasó de la etapa de Pregunta a la etapa de Creación dentro de la circunstancia pyCreatedByChannel = Mashup de la regla de tipo de caso BookEvent .

El data transform PostCaptureCustomer está circunstanciado usando la plantilla de circunstancia pyIsMashup. La diferencia es mínima. La regla básica obtiene .CustomerGUID de D_ContactEditable.pyGUID. La regla circunstanciada obtiene .CustomerGUID de D_ContactSelfServiceEditable.pyGUID.

Las secciones PostCaptureCustomer y EditEventDetails también se editan usando la plantilla de circunstancia pyIsMashup. Si estas secciones se guardan en PostCaptureCustomerBase y EditEventDetailsBase, respectivamente, las dos secciones originales pueden modificarse para embeber dos secciones en las que un privilegio de vista controla la visibilidad de dichas secciones.

Interfaz de mashup de aprobaciones de autoservicio de la aplicación de reservas

Se necesita muy poco para definir la interfaz de mashup de aprobaciones de autoservicio en el nivel de la aplicación de reservas porque prácticamente todo el trabajo se implementa en el nivel de la empresa. Lo único que se necesita es una pila de aplicaciones que llegue al nivel en el que una anulación de la sección ContactSelfServiceApproval muestre datos reales.

La interfaz de mashup Display a page (Mostrar una página) abre el harness RegisterContact definido por la empresa que se aplica a la clase FSG-Data-Contact-SelfService. La anulación FSG-Booking-Work-BookEvent de la sección ContactSelfServiceApproval embebe una sección llamada CustomerQuoteReview. Como su nombre lo indica, esta sección de solo lectura no muestra los costos ni las ganancias. Muestra el campo DiscountPercentage, que un ejecutivo de ventas puede manipular, pero el cliente no. Un ejecutivo de ventas puede decidir ofrecerle un descuento a un cliente de autoservicio antes de solicitar la aprobación de dicho cliente.

Portal de ventas

Aunque no está directamente relacionado con las dos interfaces de mashup, es importante mencionar cómo el portal personalizado del ejecutivo de ventas facilita el autoservicio del cliente.

Un harness BookEventActiveQuotes está embebido dentro del harness Sales que, a su vez, se muestra en el portal BookingSales. Las tres reglas se aplican a FSG-Booking-UIPages.

La sección BookEventActiveQuotesContent embebe una sección sin plantillas llamada BookEventActiveQuotesList que tiene un layout de tabla que se obtiene de D_BookEventQuotationStageList, que no tiene ningún parámetro. 

La página de datos de dicha lista se obtiene de una definición de reportes llamada QuotationStageBookEvent. La definición de reportes consulta cada caso BookEvent que está en la etapa de cotización. El reporte se une a FSG-Data-ContactIssuedApproval por ContactIssuedApproval CaseRef = BookEvent pyID. La unión es necesaria para mostrar si el cliente aprobó o no la cotización. 

Si Approved = true, el miembro del departamento de Ventas puede continuar con el caso BookEvent. Si no es así, el miembro de dicho departamento puede comunicarse con el cliente o esperar a que la asignación de la cola de trabajo expire después de 14 días.