How to Proxy an Unsupported Interface Type

TSL Ping Tree > How To

How to Proxy an Unsupported Interface Type

When it comes to posting leads out of ping trees our intention is to support all common interface types with no need for programming skills.  But what can be done when there is a need for an as-yet supported interface type?  For example, we do not support any kind of interface where we guarantee that posts will come from a single dedicated IP address and port number pair.  We also do not support client-side SSL certificates.  Over the years we have encountered these two specific and related requests only a handful of times and the price that customers have been willing to pay to have us develop and support these capabilities has yet to be enough to justify adding them.

But there is a way for you to implement an interface type that the system does not natively support:  Create a proxy server (a.k.a. bridge or gateway) between our system and the target system.  If you do not have your own technical resources then you can place a bid on one of the freelance programmer websites.

  1. Choose an interface type that our system does support and build and host a receiver for it anywhere you wish.  We suggest you use HTTPS POST -- it's secure and fairly simple.  Alternatively simple XML or SOAP over SSL is a good choice.

  2. Take a post that is delivered in step 1 and map it to the one or more posts required to fully interface and handshake with the external system.

  3. Based on the outcome from step 2 respond with what happened in a way that our system supports.  We suggest a simple XML format with a unique response ID, a disposition, an optional redirect URL, an optional receivable amount, and an optional block of warning or error messages.

If step 2 takes too long to run or for any other reason it is infeasible to respond in a reasonable time regarding what happened then put step 3 before step 2.  In this case just respond with an acknowledgement that the post was received and that it looks good or bad in some way.  It would still be a disposition of accept or decline but you would probably not want to configure a receivable event to be raised on an accept.

This technique can also be used when some of the features of the system that you need are only available in a more expensive edition.  Rather than upgrade to a more expensive edition you can implement just what you need elsewhere.  For example, the ability to sell aged leads on a scheduled basis is not a feature in the Starter Edition of our system.  With a bridge, its own way to securely store those leads, and its own way to resubmit those leads to our system on a scheduled basis then this functionality can be achieved.