Versions Compared

Old Version 6

changes.mady.by.user Jonas Nielsen

Saved on

compared with

New Version Current

changes.mady.by.user Jonas Nielsen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

com.cdrator.integration.utils.rator-utils-restutils
com.cdrator.core:rator-engine-api
com.cdrator.util.rator-logging
com.cdrator.workflow.hookpoint-stats
com.cdrator.workflow.hookpoint-documentation
com.fasterxml.jackson.core:jackson-databind
com.fasterxml.jackson.core:jackson-core
org.glassfish.jersey.media:jersey-media-json-jackson
javax.ws.rs:javax.ws.rs-api
org.glassfish.jersey.core:jersey-client
org.apache.commons:commons-lang3
com.google.guava:guava

Source code for the module can be found in bitbucket: https://bitbucket.org/cdratorenghouseglobal/nw-ra-rator-insurance-no-squaretrade

Square Trade API Documentation

...

View file
nameSquaretrade Sales OrderAPI Specification 5.0.pdf
View file
nameSquareTrade_ItemUpdateAPI - DRAFT.pdf
View file
nameSquareTrade Cancellation API_v5_10012020.pdf

Also note, that they are not 100% correct, a couple of errors have been regarding the URL’s and the multiple credentials. (see under configuration)

Implementation

The project consist of a new engine, as it is heavily dependent generic order and custom logic in the customer project.

...

The engine (com.cdrator.insurance.inquiryengine.SquareTradeOrderInquiryEngine) checks waiting generic orders with the partner code “SQUARE_TRADE”.
It used the response parameter “CHECK_DATE” set on the order to determine when to inquiry the specific orderSquareTradeOrderInquiry objects where the LAST_CHECKED_DATE is before sysdate + a configurable amount of seconds.
it is then inquiring about the status with Square Trade and updating its own status and the status of the generic order according to the response.

EngineParameters

One optional extra parameter exist:

...

  • Receive a list of generic orders

  • Retrieve the status of the order from square trade

  • If response is either success or error, update the order

  • Regardless of the response, update the last checked date to sysdate

Configuration

Parameters

Square trade allows for multiple set of parameters, they are configured in the parameter tree under the node INSURANCE.SQUARE_TRADE.(credentialParameterName).

Note that the credentialParameterName is optional, but advised, as squaretrade currently requires different credentials depending on the SKU.

The following parameters are used in the rator-insurance-no-squaretrade module.

INSURANCE.SQUARE_TRADE

NAME

EXAMPLE VALUE

MANDATORY

DESCRIPTION

BASE_URL

api-stage4.squaretrade.com (test)

Yes

The base endpoint for the Telenor Wholesale REST API.

CLIENT_ID

N074R341V41u38u7C10533n0u9hR19h7

Yes

The value to use for the client_id part of the client_id:client_secret credentials that must be Base64-encoded and can then be used to call endpoint oauth/v2/token; see also parameter CLIENT_SECRET.

CLIENT_SECRET

4n07h3rF4k3V41u3

Yes

The value to use for the client_secret part of the client_id:client_secret credentials that must be Base64-encoded and can then be used to call endpoint oauth/v2/token; see also parameter CLIENT_ID.

USERNAME

api_F4k3V41u3

Yes

The value to use for the username argument in the call to endpoint oauth/v2/token; see also parameter PASSWORD.PASSWORD

M0r3F4k3V41u3sF0r3v3r

Yes

The value to use for the password argument in the call to endpoint oauth/v2/token; see also parameter USERNAME.

TOKEN

No

If branded USERNAME,PASSWORD,CLIENT_ID, CLIENT_SECRET parameters are used, this parameter has to be created manually.

The currently valid token for authorization.

This will be automatically populated if there is only one set of credentials used. If multiple sets of credentials (USERNAME,PASSWORD,CLIENT_ID, CLIENT_SECRET) are used via branding of parameters, in combination with a set of non-branded/default credentials, this parameter has to be created beforehand, so as not to interfere with the non-branded/default one.

TOKEN_EXPIRY

No

If branded USERNAME,PASSWORD,CLIENT_ID, CLIENT_SECRET parameters are used, this parameter has to be created manually.

The point in time at which the current token will expire.

This will be automatically populated if there is only one set of credentials used. If multiple sets of credentials (USERNAME,PASSWORD,CLIENT_ID, CLIENT_SECRET) are used via branding of parameters, in combination with a set of non-branded/default credentials, this parameter has to be created beforehand, so as not to interfere with the non-branded/default one.

MERCHANT_ID

RATOR

Yes

Despite being sent as part of the payload for a new insurance request, merchant id is part of the credentials, as a merchant id is linked to a specific client id and secret.

Tables

One new table needs to be added to handle the inquiry status:

SQUARE_TRADE_ORDER_INQUIRY

NAME

DESCRIPTION

ID

Standard rator id.

STATUS_ID

The status of the inquiring, can be 0 (waiting), 1 (success) and 5 (error)

GENERIC_ORDER_ID

The id of the generic order this was created from.

SQUARE_TRADE_ID

The instance id sent to Square Trade.

CREATE_DATE

The date this object was created.

LAST_CHECKED_DATE

The last time this has been inquired.

ERROR_MESSAGE

Any error message returned from Square Trade.

CREDENTIAL_PARAMETER_NAME

The parameter node to find the credentials under.

Implementation in customer project.

Due to how much of the required data that is not stored in rator core, the entire process of creating request, filling out the required data and sending the request, has to done in the customer project.

Logging

Logging of the connection is done in the CLIENT_LOG table with the client name SQUARE_TRADE and either the inquiry or generic order id.

Examples of the exact payloads can be seen in the attached documentation.