4 Multiple Cores
This chapter describes the concept and procedures of setting up EFTLink using Multiple Cores.
EFTLink can be configured to use multiple cores for the purpose of redirecting requests based on:
-
Line Display
-
Request Type
-
CardRange.xml
-
Referrals
Figure 4-1 Multiple Cores
Line Display
Sale State Notification requests can either be disabled altogether or be forwarded to either one core or a delegated list of cores.
Preselected Cores
Preselected cores are configurable within the eftlinkconfig.properties
file. You can configure EFTLink to forward requests to a particular
core based upon EWallet, GiftCard (Card Service Request) or a Custom
Form (Device Request).
CardRange.xml
EFTLink always checks the cardrange.xml before determining which core is selected for handling the card Service Request.
The cardrange.xml offers EFTLink the ability to redirect card service requests to preselected cores base on the *card pan or card type.
*As the POS is not subject to sending an EMV PAN due to PCI regulations. Card PAN is only applicable with non-PCI transactions (Gift card or Ewallet).
Referrals
EFTLink supports a referral feature whereby a core can request that another core handles the request on its behalf.
By default, EFTLink sets the main core (core 0) for referrals however
this is configurable via EFTLinkConfig.Properties
.
The cardrange.xml can also be used to redirect the referral to any active core.
A referral could be based upon a feature not supported or, it could be based upon a particular failed response / error code.
The core requesting the referral is in control and is responsible for the transaction response back to the POS.
EFTLink Multiple Core Feature
EFTLink can be configured to use multiple cores for the purpose of redirecting requests based on:
-
Line display
-
Request Type
-
Cardrange.xml
-
Referrals
Figure 4-2 Multiple Cores
Line Display
Sale State Notification requests can either be disabled altogether or be forwarded to either one core or a delegated list of cores.
Preselected Cores
Preselected cores are configurable within the eftlinkconfig.properties
file. You can configure EFTLink to forward requests to a particular
core based upon EWallet, GiftCard (Card Service Request) or a Custom
Form (Device Request).
CardRange.xml
EFTLink always checks the cardrange.xml before determining which core is selected for handling the card Service Request.
The cardrange.xml offers EFTLink the ability to redirect card service requests to preselected cores base on the *card pan or card type.
*As the POS is not subject to sending an EMV PAN due to PCI regulations. Card PAN is only applicable with non-PCI transactions (Gift card or Ewallet).
Referrals
EFTLink supports a referral feature whereby a core can request that another core handles the request on its behalf.
By default, EFTLink sets the main core (core 0) for referrals however
this is configurable via EFTLinkConfig.Properties.
The cardrange.xml can also be used to redirect the referral to any active core.
A referral could be based upon a feature not supported or, it could be based upon a particular failed response / error code.
The core requesting the referral is in control and is responsible for the transaction response back to the POS.
Multiple Iterations of the Same Core
It is possible to have two or more iterations of a core. For example, if you had two different endpoints that dealt with specific tender types. Ewallet tenders went to one endpoint whereas standard CC/Debit tenders went to a different endpoint.
Such configuration requires two separate opiretail.properties
file. To accomplish this:
-
Within the
EFTLinkConfig.properties
file Core<x> property, you will need to specify the relative working folder for each core.For example:
EPSCore0 = oracle.eftlink.opiretail.OPIRetailCore WorkingFolder:./OPICore1
EPSCore1 = oracle.eftlink.opiretail.OPIRetailCore WorkingFolder:./OPICore2
-
In the EFTLink installation folder, create the declared sub folders and place the tailored
opiretail.properties
into their own subfolder.