We are getting huge lag i.e 500 ms in receiving SMS acknowledgement from SMSC, resulting in very poor throughput in sending bulk campaign sms.
So in this context client has suggested, while sending in bulk change the Pega OOTB code to not wait for SMS response/acknowledgement and send subsequent sms so that through put remains good, however at the same time they do want us to collect all the acknowledgement in some alternate way for business reporting and retry.
Now in Pega Marketing 7.22 I don't see any OOTB way of achieving the above, however we checked the PM 8 code, there we found that PEGA has introduced com.pega.mkt.sms.async.NCLSMSAsyncClient and com.pega.mkt.sms.sync.NCLSMSSyncClient APIs in there SendSMSMessage function giving the impression may be the above client ask is possible.
So in this regard I have below two question
1. Will the above code APIs/code satisfy customer need of not waiting for SMS response/acknowledgement hence increasing the throughput , but at the same time collect it for business reporting and retry.
2. Is it possible to backport the above APIs and code to pega 7.22 in order to satisfy customer need, as client is not keen to have another upgrade because we had an upgrade in 2017.
You are right, only from Pega Marketing 7.4 the async SMS delivery is supported, not in the previous releases.
The latest GA is 8.1 as of today and 8.2 coming out very soon.
The way async delivery works is by sending a bunch of messages without waiting for an acknowledgment.
But, there is a threshold for this, which could be controlled by the settings in the SMS account level inside Pega Marketing.
In other words, its the maximum number of outstanding requests sent to the SMSC without have receive a response for any number (for example : 2000)
So it would boost overall outbound performance, in situations like yours where there is a big network lag between SMSC and the Pega connection, but as mentioned like above, it's not going to totally ignore acknowledgments. You will have some flexibility to play around with the un-acknowledged queue size for your setup.
It's very difficult to back port this feature in 7.22, given a lot of design changes around this work.
You will have to upgrade at least to Pega Marketing 7.4 or higher preferably.
Will like to clear one more small doubt, you mentioned that this async feature it's not going to totally ignore acknowledgments. You will have some flexibility to play around with the un-acknowledged queue size for your setup.
So does this Async feature enables the feature of Retry for failed messages and eventually report business of the failed sms after all retry attempts are completed.
The async capability is independent of retry for failed messages. The retry of failed messages will happen by default up to 3 times (which could also be controlled by a system setting).
Remember a lag in the network is not considered as a failure - unless the lag is so bad and the timeout kicks in to mark the message as failure.
So yes retries are supported, but I don't want you to confuse between async delivery and retry of failed messages.
On the reporting of failed messages, the status is just marked to failed in the SMS queue related table, though there is no OOTB reports on these as of now, if need be, you can create reports under the relevant classes easily to give you a summary or detailed reports.
Yes I completely understand that async delivery and failure message retry/reporting are two seperate things.
The only reason I wanted to clarify this because I wasn't sure how can this two things go hand in hand, I mean if you don't wait for acknowledgement, then later how system correlates which which acknowledgement was for which original sms from pr_data_corr_sms table and how the retry attempts and errormessage are updated in this table.
Also in the below code snippet of sendsmsmessage functions I saw that after sending the message there is a thread wait, giving the impression it any way waits for the response, so again I was unsure if async feature actually works and how retry goes along with it.
Note that in addtion to async SMS delivery, we introduced multi node scaling for SMS delivery in 8.1. So the version to consider is 8.1 or 8.2 and it is recommended you run a performance test yourself to familiarise yourself with the performance impact given your SMSC and its various parameters.