| Menu: | Support -> System Management -> Service Provider/Routing -> Service Routing |
A Company can have several Service Providers for different purchase types. The routing page determines what provider will be selected for a specific purchase type.
Row 1 displays a routing with 2 providers where the first on "Is required For Purchase" (IRFP)
How a routing is selected
| Note: It is now possible to use Online Purchase Transfer (ongoing purchase) with terminals of type MP In case of a MP terminal the SubmitOngoingPurchase and SubmitPurchaseState jobs are not needed. |
All routings for a company are ordered on their priority and filtered on the provider type to be used.
then the first routing will be evaluated against the article, Tariff Package, terminal group, and parking zone. Blank values are valid. If a routing has values in more than one column, all values must match the data from the purchase
In the example above the purchase use a Tariff Package "Vehicle Charge".
If this is not the case the next row will be evaluated. If the purchase matches all four arguments listed, the message will be sent to the provider "OngoingPurchaseSOAPTestService (IRFP)" and no further evaluation will be done. Otherwise the message will be sent to the last routing as it has no rules assigned.
| Note: IRFP = "Is Required For Purchase". If a message has this option checked, WebOffice will wait for a response from this provider. If the request is denied, no further action will be taken, and the purchase will be cancelled in the terminal. |
Using more providers
From WebOffice 2.28 it is possible to route a message to more than one service provider.
In the example above, the message will be sent to ChargeStorm (IRFP) and to cale. Normally the providers are listed alphabetically but, in this case, ChargeStorm has be set to "Is Required For Purchase" and is listed first.
| Note: When a provider is set to "Is Required For Purchase", the message will be sent to this provider first. After the provider approves the purchase, the message will be sent to the other provider(s) |
Next steps:
•Add a Service Routing for Online Purchase Transfer
•Add a Service Routing for Purchase Pre-Requisites
•Add a Service Routing for Geofencing Search
•Add a Service Routing for External Information search
Circuit Breaker
The circuit breaker will prevent sending requests to a service provider when it for some reason does not respond.
See Circuit breaker for a detailed description om how it works.
A circuit breaker is defined for each service routing item. This means that stability problems are isolated to a specific customer for a specific service provider.
| Note: A service routing can contain more than one provider. In that case a circuit breaker is created for each provider in the routing |
No external id is sent to the terminal if the routing is set to "Is Required For purchase (IRFP=true)". This purchase will fail as if it is denied by the provider. Otherwise, the external id will be set to "Offline yyyyMMddHHmmssffff", the external Description to "Accepted", and the resultCode to 1. All three values will be sent to the terminal.
The same logic is implemented for the offline processing flow. An attempt is made immediately in the offline processing flow when the online request fails. The re-processing schedule in the offline processing flow is not synchronized with the circuit breaker which should be considered:
Example:
The service provider fails in the online request and in the subsequent offline request. The offline processor will schedule a new attempt based on the re-processing settings in the offline processing service, typically 5 minutes later. If the circuit breaker’s time setting SecondsToWaitOnFailure would be set to a longer time than this, it would cause unnecessary calls being made by the offline processor because it would try to execute the job, but it would be blocked before sending it to the third party and the number of retry attempts would still increase.
To avoid this the setting "Seconds To Wait On Failure" should be significantly smaller than the retry interval setting.
Example: Is Required For Purchase
If a provider is set the "Is Required For Purchase" and a message sent to this provider fails, no further actions will be taken.
If a routing contains more than one provider where all a not required for purchase and one has a circuit break, all other providers WILL receive the message.
Viewing the status of the circuit
The state of a circuit can currently only be viewed in the Offline Reprocessing Queues. it is currently only implemented for the Ongoing Purchase Reprocessing Queue.
Post Payment transaction information
A CWT terminal does not send an ongoing purchase message when it processes a Post Payment request. When a service provider needs this information, WebOffice will generate a message for this. To be able to determine when to create this message, a parameter "Used Also For PostPayment Transactions" has been added to the Service Routing. When this flag is set, a normal Ongoing Purchase transfer message will be generated. These requests are handled in the Offline Processing queue.
It is possible to add the Post Payment transaction GUID to the message. see Create a Service Provider and Specification of SOA service request and response for a description of this field.
