IPS-Huskeliste ved integrasjon

Ved oppsett av IPS integrasjon, er det en del punkter det er greit å ha et bevist forhold til. Under er en liste over anbefalte "OBS punkter" man bør ha fokus på og sette seg inn i.

IdPreference innstillinger

Sjekk ut IdPreferences, og gjør deg opp en mening om hvilke av disse innstillingene som passer ditt behov best. Diskuter gjerne med Buypass hvis du er usikker på hva dette innebærer, og hva slags kortmasser du eventuelt utelukker/inkluderer.

Konfigurasjonsmuligheter og dynamikk rundt dette

Ha et bevist forhold til B og M kategoriserte parametere. Disse bør legges opp til å være konfigurerbare. Disse parameterene varierer gjerne fra eksempelkoder, brukersteder og hvilket miljø du kjører i (test vs. prod)

GUI varianter

IPS kan kjøres som en såkalt "fullsize" GUI, eller i FRAME/IFRAME's. Gjennom fullsize GUI'en vil brukeren rutes over til IPS i hele nettleseren. Dette er et veldig enkelt skjema. Gjennom bruk av FRAME/IFRAMES vil også brukeren rutes over til IPS, men kun i en innkapslet del av nettsiden til brukerstedet. IPS sender med såkalte P3P Privacy Statements i alle HTTP headere, som bl.a. forhindrer IPS' sessionscookies i å bli oppfattet som tracking cookies selv om de i praksis er third-party cookies i en IFRAME sammenheng.

Protokoll versjonsnummer og oppdateringer av Integrasjonsbibliotek

Når du laster ned et integrasjonsbibliotek, er denne "merket" med et protokoll versjonsnummer (konfigurasjonsparameteren cnl.wips.remote.bx.ns.version). Normalt er dette siste gjeldende versjonsnummer på det tidspunktet denne distribusjonen ble satt sammen. Forskjellige versjoner av distribusjonene er kompatible på tvers av BX NS/protokoll versjoner. Når du laster ned eventuelle oppdateringer/nye versjoner, kan det derfor være at dette versjonsnummeret har blitt oppdatert. Dette betyr at fra det tidspunktet du tar i bruk disse oppdateringene, vil det nye versjonsnummeret bli sendt med i forespørslene til IPS. Dette betyr videre at IPS også vil begynne å svare med denne versjonen. Dette kan potensielt bryte implementasjonen din, da nye elementer kan være lagt til/ha endret betydning, eller at elementer har blitt tatt bort. Marker derfor alltid koden din med versjonsnummeret du har implementert støtte for, gjerne ved å hardkode dette på f.eks. i boot-strap tidspunktet

WipsRemoteConfig.setProperty("cnl.wips.remote.bx.ns.version", "1.0.1");

hvis det er versjon 1.0.1 du har implementert etter. Når du f.eks. ønsker å ta i bruk funksjonalitet som er tilkommet i nyere versjoner (f.eks. 1.0.2), endrer du det hardkodede versjonsnummeret til den ønskede verdien, og implementerer støtte for de nye tingene. Alle elementene i BX Namespace er versjonerte, slik at du enkelt kan se hvilke elementer som hører til hvilke versjoner.

Representerer du en eller flere brukerstedsID'er?

Avhengig av om du alltid skal kjøre med samme brukerstedsID, eller om applikasjonen din skal utføre operasjoner på vegne av andre brukerstedsID'er, brukes forskjellige API'er av BxRequestkonstrukturen. Alle nøkkellagre for alle brukerstedsID'er må konfigureres i WipsRemoteConfig. Typisk vil BxRequest konstrueres ved hjelp av new BxRequest(String requestName, BxElement e, boolean prepare) når du bruker en enkel brukerstedsID, mens du gjerne ville brukt new BxRequest(String requestName, BxElement e, boolean prepare, String merchantId) når du representerer en annen brukerstedsID. Logikk for nøkkelutvalget basert på brukerstedsID ser slik ut (det samme gjelder alias og passord):

public static String getKeystorePath(String merchantId){
        if(merchantId == null){
            return getString("cnl.wips.remote.keystore.path");
        } else {
            return getString("cnl.wips.remote.keystore." + merchantId + ".path");
        }
    }