Precios de promoción omnicanal de SAP: habilite el procesamiento de salida con SAP Cloud Integration
By s4pcademy
Precios de promoción omnicanal de SAP con su mantenimiento de promociones integrado ofrece un paquete completo para mantener promociones y calcular precios de venta efectivos. Más allá del servicio de cálculo, la solución también incluye el servicio de Acceso a Datos (mediante OData) para la lectura de precios y promociones. SAP Omnichannel Promotion Pricing solo admite escenarios en línea. Sin embargo, puede haber escenarios de clientes específicos que requieran capacidades fuera de línea, como Punto de venta omnicanal de SAP de GK o el llamado «Caja negra». Para estos escenarios, sería útil utilizar el IDoc existente /ROP/PROMOCIÓN03 para replicar datos de SAP Omnichannel Promotion Pricing a las aplicaciones correspondientes.
En este blog, aprenderá a usar SAP Cloud Integration para enviar el formato IDoc respectivo usando el servicio de acceso a datos para leer los datos.
El iFlow de ejemplo (flujo de integración) también administra una variable de marca de tiempo para manejar adecuadamente la replicación de actualizaciones.
El siguiente diagrama ofrece una descripción general del proceso completo.
Echemos un vistazo al flujo de alto nivel antes de profundizar en el tema:
- Inicie el iFlow con un temporizador para iniciar el procesamiento de salida con regularidad.
- En el primer paso del proceso, lea la marca de tiempo de la última ejecución exitosa del iFlow.
- Antes de que se active la llamada al servicio de acceso a datos, prepare la declaración de filtro en un script de Groovy.
- En el siguiente paso, llame al servicio de acceso a datos para recuperar los datos.
- Después de la llamada, verifique si se encuentran promociones para la configuración del filtro. Si no se encuentran promociones, vaya al paso 8.
- Ahora, los datos recibidos se asignan desde el formato OData del servicio de acceso a datos al
el formato IDOC de la promoción
- Una vez que se asignan los datos, el mensaje se envía a un punto final HTTP REST correspondiente.
- Se analiza el código de respuesta de la llamada HTTP y, en caso de una ejecución exitosa, se ajusta la marca de tiempo.
- La nueva marca de tiempo se almacena en una variable de todo el arrendatario de CPI para que la utilicen las llamadas posteriores.
En las siguientes secciones, estos pasos se explican con más detalle.
Temporizador
En el siguiente ejemplo, el iFlow se inicia cada 10 minutos:
Leer marca de tiempo
Utilice un modificador de contenido para leer la variable global que almacena la última ejecución exitosa del iFlow. Además de esto, genera una nueva marca de tiempo:
Manejar parámetro de consulta
En esta parte, prepare la llamada del servicio de Acceso a Datos. Consiste en dos pasos:
- Verifique la marca de tiempo y cree la parte del filtro de la consulta
- Construir la cadena de consulta de OData
En las siguientes líneas de código, verifique si se proporciona la variable de marca de tiempo. (Esto siempre debería ser cierto después de la primera ejecución exitosa). Si se proporciona la marca de tiempo, construya un filtro que seleccione todas las promociones que se han cambiado entre la última ejecución exitosa y ahora). En caso contrario, se seleccionan todas las promociones:
def properties = message.getProperties() as Map<String, Object> ;
def timestampValue = properties.get("timestamp");
def newTimestampValue = properties.get("newTimestamp");;
// adjust new time stamp to the format used within Omnichannel Promotions Pricing Service
newTimestampValue = newTimestampValue.replace(" ", "T") + ".000Z";
message.setProperty("newTimestamp", newTimestampValue);
def filterValue = "";
if (timestampValue != null && timestampValue.length()>0) {
filterValue = "\$filter=changedOn%20gt%20datetimeoffset%27" + timestampValue + "%27%20and%20changedOn%20le%20datetimeoffset%27" + newTimestampValue + "%27";
}
Después de definir el filtro, agregue también una instrucción $expand adicional para garantizar que la respuesta de la llamada del servicio de acceso a datos incluya los datos de promoción necesarios (consulte Nota OSS 2777975 para detalles).
message.setProperty("customQuery",
filterValue
+ "&\$expand=promotionPriceDerivationRules,promotionPriceDerivationRules/priceDerivationRule,promotionPriceDerivationRules/priceDerivationRule/externalActionRuleParameters,promotionPriceDerivationRules/priceDerivationRule/externalActionRuleTexts,promotionPriceDerivationRules/priceDerivationRule/mixAndMatchPriceDerivationItems,promotionPriceDerivationRules/priceDerivationRuleEligibilities,promotionTexts,businessUnitAssignments,merchandiseSetNodes,merchandiseSetHeaders,promotionPriceDerivationRules/priceDerivationRule/addBonusPriceDerivationItems");
return message;
Obtener datos de SAP Omnichannel Precios de promoción
En el siguiente paso, utilice el adaptador receptor de OData para llamar al servicio de acceso a datos.
En la pestaña de proceso, defina los detalles para la llamada OData:
Seleccione una ruta de recurso. Para la fuente de conexión, use la opción Archivo EDMX local.
Descargue el archivo EDMX necesario de SAP Centro de negocios API.
Para el mapeo, es importante generar una definición de esquema XML (nombre marcado en verde).
Luego, seleccione todos los campos excepto la referencia posterior «promoción» en «promotionPriceDerivationRules» (vea la línea marcada en azul).
La consulta generada es muy compleja. Por lo tanto, elimine la cadena de opciones de consulta y use la consulta personalizada que preparó en el script Groovy en el paso anterior:
Verificar contenido
Después de llamar al servicio de acceso a datos, introduzca un enrutador para llamar al receptor de IDoc solo si el servicio de acceso a datos proporcionó al menos una promoción. Usa lo siguiente expresión XML para comprobar esto:
Asignación de mensajes
El siguiente paso es el mapeo de la respuesta de la llamada del servicio de acceso a datos al formato IDoc de promoción.
En el lado de la fuente, seleccione el archivo XSD que ha creado en la definición de llamada de OData:
Ahora se pone un poco complicado. Debemos diferenciar entre los siguientes casos:
- Necesita el IDoc en formato XML y tener a mano el IDoc XSD (probablemente de la transacción WE60 del sistema CARAB). Asegúrese de que el sistema CARAB proporcione el formato actual que incluye todos los campos necesarios.
- Necesita el IDoc en formato JSON.
- Necesita el IDoc en formato XML pero no tiene un archivo XSD.
Caso 1
Tiene acceso a un XSD y planea enviar el IDoc en formato XML.
En este caso, es sencillo: use el IDoc XSD para el mensaje de destino en un iFlow de la siguiente manera:
Caso 2
En este caso, debe descargar la documentación de OpenAPI desde el Centro de API empresarial de SAP. Desafortunadamente, la asignación de SAP Cloud Integration no admite la definición de esquema utilizada por la definición de la API de carga de datos:
...
"requestBody": {
"content": {
"application/json": {
"schema": {
"oneOf": [
{
"$ref": "#/components/schemas/_-ROP_-BASE_PRICE01"
},
{
"$ref": "#/components/schemas/_-ROP_-PROMOTION02"
},
{
"$ref": "#/components/schemas/_-ROP_-PROMOTION03"
}
]
},
...
Por lo tanto, cree su propia copia local y ajuste el elemento «esquema» en consecuencia:
...
"paths": {
"/idocinbound": {
"post": {
"security": [
{
"OAuth2": [
"{xsappname}.InboundProcessing"
]
}
],
...
"requestBody": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/_-ROP_-PROMOTION03"
},
Use la copia local para importar el formato del mensaje de destino («Cargar promociones usando OAuth2» -«/idocinbound» – «POST» – «REQUEST») Ver el blog Integración con la nube de SAP: Swagger/OpenAPI Spec JSON en el mapeo de mensajes para mas detalles.
Caso 3
En este caso, realice exactamente los mismos pasos que se describen en el caso 2, pero además, debe convertir el mensaje en el formato XML correspondiente después de realizar la asignación:
Cartografía
Ahora el trabajo de mapeo puede comenzar:
Puede encontrar información detallada sobre el sistema de origen y el sistema de destino en SAP API Business Hub: Acceso a los datos y Carga de datos
Dado que el IDoc proviene del mundo ABAP y los servicios OData brindan formato Java, debe convertir varios campos. Esto se puede hacer con scripts cortos de Groovy:
Fecha y hora:
def String convertToAbapDateTime(String javaDateTime){
def result = "";
if (javaDateTime.length()>20) {
result = javaDateTime.substring(0,4) + javaDateTime.substring(5,7) + javaDateTime.substring(8,10);
result = result + javaDateTime.substring(11,13) + javaDateTime.substring(14,16) + javaDateTime.substring(17,19);
}
return result
}
Booleano:
def String convertToAbapBoolean(String booleanValue){
if ("true".equals(booleanValue))
return "X"
return ""
}
Se necesitan más asignaciones, por ejemplo, para el tipo de unidad de negocio:
def String mapBusinessUnitType(String businessUnitType){
def result = "";
if ("RetailStore".equals(businessUnitType)) {
result = "1040";
}
else if ("Distribution Center".equals(businessUnitType)) {
result = "1002";
}
return result;
}
La lista no está completa, pero espero que te hagas una idea.
Receptor de IDOC de llamada
Después de la asignación, use el receptor HTTP para llamar a un punto final del receptor IDoc:
Verifique el estado y actualice la marca de tiempo
Después de la llamada, verifique el estado antes de sobrescribir la marca de tiempo con la nueva. Esto se hace en un script de Groovy correspondiente usando la propiedad CamelHttpResponseCode, que incluye el estado HTTP de la última llamada:
def headers = message.getHeaders() as Map<String, Object>;
def status = headers.get("CamelHttpResponseCode");
if (status != null && status == 200 ) {
def properties = message.getProperties() as Map<String, Object> ;
def newTimestampValue = properties.get("newTimestamp");;
message.setProperty("timestamp", newTimestampValue);
}
return message;
Escribir marca de tiempo
En el último paso del iFlow, almacene el valor actual de la marca de tiempo (que sigue siendo el antiguo, si falla la llamada de IDoc). Esto lo hace el módulo de variables de escritura:
Este es solo el flujo básico y puede haber otros puntos a considerar en escenarios más complejos:
- La compatibilidad con varios receptores necesitaría trabajo adicional, por ejemplo, introducir una variable de marca de tiempo por receptor y extraer el proceso central en un iFlow de reutilización.
- Para evitar ataques DoS, SAP Omnichannel Promotion Pricing tiene un límite de tamaño y, según la complejidad de su promoción, la cantidad de promociones que proporcionará el servicio de acceso a datos puede estar restringida (hasta 1000). Si espera una mayor cantidad de promociones para la carga inicial, es posible que deba introducir un bucle para llamar al servicio de acceso a datos varias veces con un tamaño de paquete correspondiente (usando los parámetros top y skip de OData).
- La solución descrita en este blog no proporciona un «proveedor de IDoc» habitual. Debe completar el segmento de IDoc correspondiente de manera que el receptor de IDoc acepte los mensajes de IDoc creados.
Sugerencia: un iFlow simple para borrar la variable de marca de tiempo habilitaría fácilmente las cargas iniciales en cualquier momento.
Restricciones
También hay algunas restricciones que debe tener en cuenta:
- Desafortunadamente, OData solo permite establecer un filtro en el encabezado de la promoción. Con eso, la restricción de un procesamiento de salida específico de la ubicación no se admite «de fábrica».
- MIN_PPS_VERSION aún no se puede mantener en el mantenimiento de promociones de SAP Omnichannel Promotion Pricing. Por lo tanto, un receptor puede obtener algunas promociones, que no pueden procesarse correctamente sin siquiera reconocer esto.
Con este blog, le di una idea sobre cómo puede usar el servicio de acceso a datos y SAP Cloud Integration para replicar promociones mantenidas con SAP Omnichannel Promotion Pricing en soluciones fuera de línea existentes aprovechando el conocido IDoc de promoción.
No todos los aspectos, que son relevantes para una configuración productiva, se han cubierto hasta ahora. Sin embargo, se pretendía mostrar que no existen obstáculos importantes para este enfoque.
