{"id":488,"date":"2021-07-30T13:25:46","date_gmt":"2021-07-30T13:25:46","guid":{"rendered":"https:\/\/payb.co.uk\/integration-guide\/?p=488"},"modified":"2021-07-30T13:25:46","modified_gmt":"2021-07-30T13:25:46","slug":"entry-point-state-awareness","status":"publish","type":"post","link":"https:\/\/payb.co.uk\/integration-guide\/direct-integration\/entry-point-state-awareness\/","title":{"rendered":"Entry Point State Awareness"},"content":{"rendered":"
Description<\/i><\/span><\/h5>\n

This method differs from the \u2018Blind Processing\u2019 method greatly. The nature of this method is to not fire transactions at each gateway entry point in order, but to record the entry point of each successful transaction, which then in turn becomes the first entry point to try in the next transaction.<\/p>\n

How<\/i><\/span> <\/i>It<\/i><\/span> <\/i>Works<\/i><\/span><\/h5>\n

When the merchant\u2019s system is in a new or \u201creset\u201d mode, the transactions will use the above \u201cBlind Processing\u201d method. Once this transaction is successful (either transaction authorised or rejected response), the transaction result passed back to the merchant\u2019s system contains information as to the gateway entry point which processed the transaction. This entry point should be persistently stored on the merchant\u2019s system, usually in a database table record of some sort. When the next transaction takes place, it looks at that database table and uses the latest successful gateway entry point as it first entry point to attempt. Like the \u201cBlind Processing\u201d method, if this transaction fails, it will then failover to the next entry point. Again, it will do this until all the entry points have been tried and failed, or the transaction is processed successfully and once again, the successful entry point used is persistently stored ready for the next transaction.<\/p>\n

Pros<\/i><\/span><\/h5>\n

The \u201cEntry Point State Awareness\u201d method is more sophisticated than the \u201cBlind Processing\u201d method due to its awareness as to the entry points state. This allows more efficient transaction processing during times of an entry point outage.<\/p>\n

Cons<\/i><\/span><\/h5>\n

This can be an intricate piece of work to develop and implement, even in its simplest form described<\/p>\n

in the \u201cHow It Works\u201d section. The reason we say this is because you can make it even more sophisticated still, as described in the \u201cAdditional Ideas\u201d section below.<\/p>\n

Additional<\/span> Ideas<\/span><\/h4>\n

The \u201cEntry Point State Awareness\u201d method is sophisticated in the sense that it isn\u2019t just blindly firing transactions at each entry point in succession. However, the simple version explained in the \u201cHow It<\/p>\n

Works\u201d section still has its flaws but was deliberately kept minimal to get the idea across in its simplest form.<\/p>\n

One weakness of the simple \u201cEntry Point State Awareness\u201d method described above is the potential for \u201cstale data\u201d. What we mean by this is that if a transaction is processed and the successful entry point<\/p>\n

stored, but the next transaction isn\u2019t processed for an hour for example, the \u201cstate\u201d of the last successful entry point could easily be invalid. In the world of I.T and the internet, the \u201cstate\u201d of systems can change very quickly. You may have a perfectly up and running entry point one minute, something could happen and bring it down and it\u2019s then not able to process transactions. Based on this \u201cstale data\u201d, it would be worth implementing a timeout threshold on the merchant\u2019s system so that if a transaction begins to be processed, but the previous transaction time is greater than the threshold allows, the your \u201cEntry Point<\/p>\n

State Awareness\u201d is \u201creset\u201d and you begin the process again using the \u201cBlind Processing\u201d method. This will ensure not only that you\u2019re using the most successful entry point for each new transaction, but if there is a large enough gap between the previous and the next transaction, that you re-test the each entry point<\/p>\n

in succession if your \u201cstate awareness\u201d becomes stale.<\/p>\n

There is one additional piece of development that merchants can implement on their system to add yet another level of sophistication. This utilises the function \u201cGetGatewayEntryPoints\u201d found earlier in this document. What this function does is fire a very basic message at a specified gateway entry point and if the gateway entry point is up, it will return a complete list of all available gateway entry points and a metric value for each which it deems appropriate. This also means that if any of the gateway entry points are down, the entry point metric value of \u201c-1\u201d is returned for that particular entry point and the others have the metric value adjusted accordingly. The intricate part of this is that you will still need to have multiple gateway entry points to fire this basic message at. This is because, if you only have one entry point to fire this message at, and that entry point is down, then you will not yield a response from the gateway. This function will also return any NEW gateway entry points added that the merchants system may not yet be aware of which will prove to be very useful at increasing the merchants system ultra-high availability status. In order to implement this properly, you will need to have all available entry points persistently stored, in a database being the most favourable option. Then periodically (as you see appropriate) as part of a SCHEDULED server maintenance job of some description firing the<\/p>\n

\u201cGetGatewayEntryPoints\u201d message to the gateway using the \u201cGateway Entry Point State Awareness\u201d method mentioned above. When you get a successful response from the gateway, you insert any NEW gateway entry points that aren\u2019t yet in the database table, and updating all of their respective entry point metric values. The reason you never do this as part of an actual transaction is to not add any delay times to transactions whilst waiting for the \u201cGetGatewayEntryPoints\u201d message to yield its response from the gateway.<\/p>\n","protected":false},"excerpt":{"rendered":"

Description This method differs from the \u2018Blind Processing\u2019 method greatly. The nature of this method is to not fire transactions at each gateway entry point in order, but to record the entry point of each successful transaction, which then in turn becomes the first entry point to try in the next transaction. How It Works…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,63],"tags":[],"_links":{"self":[{"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/posts\/488"}],"collection":[{"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/comments?post=488"}],"version-history":[{"count":1,"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/posts\/488\/revisions"}],"predecessor-version":[{"id":489,"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/posts\/488\/revisions\/489"}],"wp:attachment":[{"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/media?parent=488"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/categories?post=488"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/payb.co.uk\/integration-guide\/wp-json\/wp\/v2\/tags?post=488"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}