The PX Notification component Web service provides
facilities for notification delivery to the requester endpoint directly
or through the Access Gateway.
This component also provides an asynchronous model for invocation,
in which an application can send a notification, continue its processing
without blocking, and then receive a delivery confirmation. This feature
is not configurable from the end user standpoint, and is only configurable
from the Web service point of view. It supports all services having
notification operations.
For more information about the PX Notification component Web service,
refer to the topic Planning for notification in this
information center.
Retry mechanism
A retry mechanism has been
added to the notification delivery of several Parlay X services that
retries the endpoint for a configurable number of times, before logging
a failure. Generally, retry occurs when the HTTP code returned for
the endpoint is 404 or 503. Specifically, retry happens under the
following scenarios:
- In the absence of an ESB endpoint, when the requester's endpoint
is down.
- In the presence of an ESB endpoint, if the endpoint is valid and
is down.
The following are possible valid endpoints:
- An ESB endpoint of the same application. For example, if you are
using an SMS application, it may be the SMS application's ESB
endpoint.
- An ESB endpoint of other applications. For example, if you are
using an MMS application, it may be the ESB endpoint of the TL application.
- Any other URI where some service must be present at the specified
location and port (except the endpoint of a service implementation
component).
The retry is done at the PXNotification component
scope and is done as long as the endpoint URI is not accessible and
the retry count is not exhausted. A retry delay is also configurable
for the pause time between the retries. However, the retry is not
persistent. If the database, application, or cluster node goes down,
the retry state will not be saved and continued from where it left.
Instead, it will start again from the beginning.
Note: The retry does
not apply to faults within the ESB notification flow. Such faults
will be logged.
Delivery mode options
Three delivery mode
options indicate how the notification needs to be conveyed to the
requester endpoint. This is usually set by the Web service implementations
and can be overridden at the PX Notification component level.
The
following are the delivery mode options:
- Inline: A single thread of execution from
the service implementation to the endpoint (ESB or requester).
- Asynchronous: The service implementation
hands over the request to the PX Notification component, which in
turn places the request in a JMS queue. The service implementation
is not blocked for a response from the endpoint. Delivery confirmation
can be obtained using the Delivery Confirmation Callback interface.
- Mode set by the service implementation:
This is the default option. The delivery mode is usually set by the
Web service implementation and can be overridden at the PX Notification
component level. Therefore, whatever delivery mode (Inline or Asynchronous)
is chosen by the service implementation is used by the PX Notification
component.
Table 1. Delivery modes used by the services Parlay X service implementations |
Delivery mode used for notification delivery
through PX Notification |
Terminal Location/Parlay |
Inline |
Terminal Status/Parlay |
Asynchronous |
Call Notification/Parlay |
Inline |
SMS/Parlay and SMS/SMPP |
Inline |
Call Notification/SIP |
Asynchronous |
Presence/SIP |
Asynchronous |
Terminal Status/SIP |
Asynchronous |
MMS/MM7 |
Inline |
Terminal Location/MLP |
Inline |