Busca respuestas existentes a tus preguntas de productos y soporte.
Familiarízate con nuestro sitio de soporte y aprende las mejores prácticas sobre trabajar con nuestro equipo.
Manejar Peticiones de Servicio. Ve y actualiza peticiones de servicio tuyas o de otros miembros de tu organización.
Reporta un nuevo problema a nuestro equipo de soporte técnico.
Conocimientos sobre el Servicio Oracle B2C por parte de expertos en el área de nuestro equipo de soporte técnico.
Explora recursos que serán útiles para poner en marcha tu implementación y asegurar un lanzamiento exitoso.
Accede a tu cuenta OCI.
Encuentra documentación del producto para versiones vigentes de B2C y bibliotecas de documentación para soluciones de servicio relacionadas.
Tendrás las herramientas para mejorar la experiencia de los clientes al aprender todo lo que nuestro producto es capaz de hacer.
Encuentra enlaces para la documentación de APIs, Procesos Personalizados, Portal de Clientes, y la Estructura Extensible de la Interfaz de Usuario del Navegador para Agentes (BUI).
Explora cómo los aceleradores son diseñados para demostrar cómo un escenario de integración podría ser construido usando integraciones públicas y las capacidades de extensión del servicio de Oracle B2C.
Prepárate para una transición exitosa al revisar cambios y mejoras próximas a ser lanzados.
Explora webinarios, eventos, y kits de características para aprender sobre las características, funcionalidades, y mejores prácticas para el Servicio B2C brindado por técnicos expertos en el área.
Oracle MyLearn ofrece un portafolio de recursos de aprendizaje basados en un modelo de suscripción gratuito y de paga para adquirir habilidades valiosas, acelerar la inclusión de la nube, incrementar la productividad, y transformar tu negocio.
Empodera a tu equipo con las habilidades para implementar, configurar, manejar, y usar tus aplicaciones con el Entrenamiento de la Nube para la Experiencia del Cliente.
Nuestro objetivo es facilitar un entorno amigable y solidario, donde los miembros pueden colaborar fácilmente entre ellos sobre soluciones y mejores prácticas.
Realiza y responde preguntas específicas a B2C.
Este es un recurso fascinante con el propósito de ayudar con el Análisis de la Nube del Servicio de Oracle.
Comparte ideas de cómo mejorar el producto y solicitudes de mejoras con el equipo de desarrollo de Oracle, mientras colaboras con otros clientes y socios de Oracle.
Actualiza tu número telefónico, preferencias de notificaciones por correo electrónico, y preferencias de contacto para incidentes de severidad 1 y 2.
Consulta los gestores de contactos dentro de tu organización.
Encuentra información de contacto del Gerente Técnico de Cuentas (TAM), y el Gerente de Éxito de Clientes (CSM) para tu organización.
Environment:
Process Designer, Custom Processes (CPM), Connect for PHP (CPHP) All product versions
Resolution:
The use of an appropriate timeout is required with use of PHP curl in a CPM customization. In addition to specifying a timeout value in code, there are other considerations to make in terms of the potential to retry the call if the request times out.
What is an appropriate timeout?
A curl call timeout of five seconds is highly recommended. This value provides enough time for most integration requests to complete and is small enough to ensure that the asynchronous CPM queue does not fall behind, or become backlogged (in other words). A larger timeout is valid if the volume of transactions processed by the queue allows for it, for any given implementation.
When a curl call reaches a configured timeout threshold, should I ensure that the request is retried?
When a request is made to an integration, and the PHP curl call hits the configured timeout, the PHP process stops waiting for the response from the integration. This, however, does not mean that the request will fail or need to be retried. Instead, the requesting PHP script will not have a response to analyze (in order to determine if the request has completed successfully or not). As such, the determination as to whether or not to retry the request depends on the individual business requirements for each specific implementation.
When a PHP curl call times out in CPM code, how do I ensure that the request is retried?
If it is determined that retrying an integration call is appropriate, this can be accomplished in different ways. One way is to utilize the inherent retry mechanism for asynchronous CPMs when triggered through a mapping in the Process Designer (only, as this does not occur for those triggered from business rules, surveys or campaigns). For further details on this see
Answer ID 6607: Asynchronous CPM "processes" queued are removed automatically after ten unsuccessful tries
This first requires that the curl call is analyzed in code, for whether or not the request timed out. If it did, then the code can throw an exception manually to ensure the CPM is retried (up to the total tries allowed). The PHP curl_errno function is recommended for evaluating the curl response, and then a manual exception may be thrown (that is not being caught in any surrounding PHP try/catch code) to signal to the parent process that there has been a failure. For details on this see
Answer ID 9640: Connect for PHP Best Practices and Gotchas
Also, if using the inherent retry functionality it is important to understand that this could cause the CPM customization to enter an error state. For further details on this see
Answer ID 10025: When does a Custom Process (CPM) enter an error state?
Alternatively, the CPM code can retry the curl call again in the same CPM run, as long as there is enough time to do so within the 157 second limit for an asynchronous CPM. Another method to retry an integration call would be to use an API save intended to re-trigger the asynchronous CPM. For the latter to be effective there must be some change made to the object when the API save is run. Custom objects or fields can also be utilized to evaluate and update objects using the APIs (CPHP etc.) from other customizations (custom crons for example, or custom scripts called externally on a schedule), with the purpose of re-triggering failed CPM runs.
In any case, when integration call retries are made it is important to understand that any object data sent to integrations will reflect the state of the object data at the time the retry of integration call is made. For details on this see
Answer ID 12386: CPMs and Event Subscriptions Not Sent or Sent with Duplicate Data
For further details see
Answer ID 8392: CPM/Process Designer Best Practices and Guidelines