How to build the client side application to trigger the real-time event?
Hi,
I would like to know the client side mechanism of real-time event activation.
I read the user guide and knew that sending SOAP request to 'http://<host>:<port>/prweb/ PRSOAPServlet/SOAP/PegaMKTDataMktEvent/Services?WSDL' triggers the real-time event.
Do we have to scratch client application such as organizing soap request with customer id, lattitude and longitude?
Or does Pega Marketing provide any materials for building client application?
Regards,
Accepted Solution
Pegasystems Inc.
US
Pegasystems Inc.
US
SOAP is a Pega independent protocol for two loosely coupled systems to interact through a defined contact (in this case WSDL). You can use any SOAP client to call Pega provided SOAP endpoint. One of the most popular ones is call SOAPUI (you can google it and download to test it out).
Accepted Solution
Pegasystems Inc.
US
The client side use cases are varied and very specific to the channel and client application. As such (as indicated by your line of questions) Pega provides an interface to activate it and not the client application implementation. The channel client application is meant to call that interface (the Pega end-point) with enough data payload to allow the system to best service the request.
For example, you might have a system already in place that knows that you are running low on funds (for example, a comms customer running out of data), so the system that knows this will call the event API with details that indicate this is a "RunningOutOfData" event, the customer ID and send to Pega. The Pega system will be setup to listen to this marketable event and call NBA, which will in turn figure out what is best to do for this customer and this event context. This is an example of there being a system that has already 'detected' an event and is just passing it on to Pega as a potential marketable event to process as an NBA.
The client side use cases are varied and very specific to the channel and client application. As such (as indicated by your line of questions) Pega provides an interface to activate it and not the client application implementation. The channel client application is meant to call that interface (the Pega end-point) with enough data payload to allow the system to best service the request.
For example, you might have a system already in place that knows that you are running low on funds (for example, a comms customer running out of data), so the system that knows this will call the event API with details that indicate this is a "RunningOutOfData" event, the customer ID and send to Pega. The Pega system will be setup to listen to this marketable event and call NBA, which will in turn figure out what is best to do for this customer and this event context. This is an example of there being a system that has already 'detected' an event and is just passing it on to Pega as a potential marketable event to process as an NBA.
Another example is where systems of record don't really know that an event has occurred, but have raw data that might indicate a marketable event is appropriate. For example, a financial institution might be interested in addressing a downward trend in credit card transactions. In this case, the financial institution would have the raw transactional data, but not a clear signal of a downward trend. In this example, Pega offers a capability (Event Strategy Manager) to stream the raw data to Pega, group the data into an average spend over 1 month period and compare it to the spend in the prior month. Only if the spend in this month is significantly below the last month, then forward it to the Marketing product as a Marketable event.
In both the cases the marketable event is activated by calling the event API. In older versions of Pega Marketing that API was implemented via the SOAP protocol. In more recent versions (8.2+ I believe), the SOAP api has been deprecated in favor of a Kafka based API that is implemented with the REST protocol. This was done to support much higher throughput/scale processing. Depending on the version of the product, please ensure you use the appropriate protocol end-point.
Hope this helps and good luck.
アビームコンサルティング株式会社
JP
Hi, thank you for your answers.
I could understand.
I also try SOAPUI in our development environment.
I really appreciate for your practical advice.
Best regards.
The client side use cases are varied and very specific to the channel and client application. As such (as indicated by your line of questions) Pega provides an interface to activate it and not the client application implementation. The channel client application is meant to call that interface (the Pega end-point) with enough data payload to allow the system to best service the request.
For example, you might have a system already in place that knows that you are running low on funds (for example, a comms customer running out of data), so the system that knows this will call the event API with details that indicate this is a "RunningOutOfData" event, the customer ID and send to Pega. The Pega system will be setup to listen to this marketable event and call NBA, which will in turn figure out what is best to do for this customer and this event context. This is an example of there being a system that has already 'detected' an event and is just passing it on to Pega as a potential marketable event to process as an NBA.
The client side use cases are varied and very specific to the channel and client application. As such (as indicated by your line of questions) Pega provides an interface to activate it and not the client application implementation. The channel client application is meant to call that interface (the Pega end-point) with enough data payload to allow the system to best service the request.
For example, you might have a system already in place that knows that you are running low on funds (for example, a comms customer running out of data), so the system that knows this will call the event API with details that indicate this is a "RunningOutOfData" event, the customer ID and send to Pega. The Pega system will be setup to listen to this marketable event and call NBA, which will in turn figure out what is best to do for this customer and this event context. This is an example of there being a system that has already 'detected' an event and is just passing it on to Pega as a potential marketable event to process as an NBA.
Another example is where systems of record don't really know that an event has occurred, but have raw data that might indicate a marketable event is appropriate. For example, a financial institution might be interested in addressing a downward trend in credit card transactions. In this case, the financial institution would have the raw transactional data, but not a clear signal of a downward trend. In this example, Pega offers a capability (Event Strategy Manager) to stream the raw data to Pega, group the data into an average spend over 1 month period and compare it to the spend in the prior month. Only if the spend in this month is significantly below the last month, then forward it to the Marketing product as a Marketable event.
In both the cases the marketable event is activated by calling the event API. In older versions of Pega Marketing that API was implemented via the SOAP protocol. In more recent versions (8.2+ I believe), the SOAP api has been deprecated in favor of a Kafka based API that is implemented with the REST protocol. This was done to support much higher throughput/scale processing. Depending on the version of the product, please ensure you use the appropriate protocol end-point.
Hope this helps and good luck.