REST Integration Specification

REST Integration Specification

Medtronic SST Core Data Cache

Sapient

10 Nov. 2014Medtronic

Nov 18, 2014

Cop yright 2015 Sapient Corporation | Confidential

Table of Contents

Table of Contents
1

Overview 4

1.1 Purpose 4
1.2 Audience
4
1.3 Glossary of Terms
4
SST Core Data Cache Queue
5
2.1 Assumptions
5
2.2 Approach
5
2.3 Process Flow -- POST
5
2.3.1 Process Flow - Request Data (multi-part request: meta data followed by
the Core Data file)
6
2.3.2 Response Data POST Core Data Cache
6
2.4 Process Flow -- GET
7
2.4.1 Process Flow - GET Request Data
7
2.4.1 Response Data GET Core Data Cache
7
2.5 Process Flow Exception Scenario(s)
7
Exception Handling Strategy
8

Logging Strategy & Design

Document References

MAY 29 2015

PREPARED BY SAPIENT FOR MEDTRONIC | CONFIDENTIAL

9
10

SST Core Data Cache Queue

Revision History

Date

Version

Description

Author

28-Oct-2014

0.1

Initial Draft- Template

Sapient Nitro

18-Nov-2014

0.2

Draft

RP Nelson - MDT

23-dec-2014

0.3

Daily updates of core data cache file desired.

RP Nelson

03-Feb-2015

0.4

Updated to match modified sync design, services,

added flow diagram, consolidated the two Core
Data Cache ISDs

P. Ericksen - MDT

May 29 2015

Prepared by Sapient for Medtronic

Page 3

SST Core Data Cache Queue

May 29 2015

Overview

Prepared by Sapient for Medtronic

Page 4

SST Core Data Cache Queue

3.1

Purpose
This document captures the REST integration requirement, design and approach for Medtronic
ecommerce platform.

May 29 2015

Prepared by Sapient for Medtronic

Page 5

SST Core Data Cache Queue

3.2

Audience
The different groups of audience members to which this document applies to are:
a)

Medtronic IT Team.

b)

Sapient Development Team

c)

Sapient & Medtronic QA Teams

May 29 2015

Prepared by Sapient for Medtronic

Page 6

SST Core Data Cache Queue

3.3

Glossary of Terms

Global Customer Self Service Portal

Spine Sales Tool

May 29 2015

Prepared by Sapient for Medtronic

Page 7

SST Core Data Cache Queue

SST Core Data Cache Queue

This integration is used to POST a Core Data (SQlite database) Cache (file) to the hybris server,
and to GET a Core Data (CD) file from the server. The CD file represents the SQlite database for
a specific user. This end point is intended to be used by Mac Mini workers which will have their
own unique service account in hybris.
The endpoint should be named: <base url>/api/v1/cache. For example, the SST mock services
endpoint is: https://entmobt.medtronic.com/api/v1/cache

May 29 2015

Prepared by Sapient for Medtronic

Page 8

SST Core Data Cache Queue

4.1

Assumptions
The following assumptions are applicable:
a)

Mac Mini worker process has logged in.

b)

Mac Mini worker login has Queue Worker group membership in Hybris.

c)

Mac Mini has successfully created a core data file for an active SST user.

May 29 2015

Prepared by Sapient for Medtronic

Page 9

SST Core Data Cache Queue

4.2

Approach
a) Use the sync endpoint to GET the full sync file for the user.
b) Use the cache endpoint to POST the core data database back to the server.
c) Use the cache endpoint to GET the core data database from the server.

May 29 2015

Prepared by Sapient for Medtronic

Page 10

SST Core Data Cache Queue

4.3

Process Flow -- POST

The POST endpoint is used to save the CD file to the hybris server. A core data database is a
SQLite database built to be quickly ingested by the mobile client. It contains a full set of data for a
given user, equivalent to a full sync. Separate business processes will exist to identify users for
which new / updated core data database files are needed. The Mac Mini worker processes will
process these requests. Detailed steps in the process are below:

1. A new database will be created for each user at least every 24 hours.
2. External business process identifies that a new core data cache database needs to be built,
for which there is no pre-existing database file or the version is old. This use case includes:
new user created, realigned user, on-demand (ex: expired cache on device due to data
refresh or logout), or manual request (help desk determines user needs full data
refresh/reinstall of application).
3. External process adds a work request to the queue.
4. The hybris server notifies the primary Mac Mini worker (responsible for managing the work
across the Mac Mini group) that new work items are on the queue. If a notification does not
occur within a configurable span of time, then the primary Mac Mini worker will periodically
poll queue to see if there is any work to do.
5. The server needs to change the status of the work items (ex: set to processing) sent to the
worker machines so that it does not resend them.
6. Once the Mac Mini workers know about work items on the work queue, then one of the Mac
Mini workers does a GET to grab the full sync file for that user, using the full sync endpoint
(see Mobile Data Sync ISD) from the Hybris server.
7. The worker processes the data sync file and creates a core data database for the user.
8. The worker compresses the core data database
9. The worker posts the compressed core data database back to the Hybris server (see
ISD_TransactionCoreDataCache).
10. Upon successful save, the server should set the status of the work queue item to completed
or processed (queue item is no longer available).

May 29 2015

Prepared by Sapient for Medtronic

Page 11

SST Core Data Cache Queue

3.1.1

Process Flow - Request Data (multi-part request: meta data followed by the
Core Data file)

Request Attribute

Data
Type

Description

sessionToken

String

Http cookie from authentication.

preferredLanguage

String

Http header. Requested language

code (e.g. EN for English). Defaults
to language of base site.

id

String

GUID of work queue item.

createDateTime

Unix
Date

userId

String

User to which this core data cache

belongs.

queueId

String

The unique identifier for the work

item that this core data file
represents

dataBytes

May 29 2015

Bytes

Comments

used by server to change

status on the work queue

In 2nd part of multi-part request.

Prepared by Sapient for Medtronic

Page 12

SST Core Data Cache Queue

3.1.2

Response Data POST Core Data Cache

An HTTP Status code of 200 OK is all that is expected from a successful response.

May 29 2015

Prepared by Sapient for Medtronic

Page 13

SST Core Data Cache Queue

May 29 2015

Prepared by Sapient for Medtronic

Page 14

SST Core Data Cache Queue

4.4

Process Flow -- GET

May 29 2015

Prepared by Sapient for Medtronic

Page 15

SST Core Data Cache Queue

3.1.3

Process Flow - GET Request Data

Request Attribute

Data
Type

Description

sessionToken

String

Http cookie from authentication.

preferredLanguage

String

Http header. Requested language

code (e.g. EN for English). Defaults
to language of base site.

userid

String

SST user id (MDT enterprise

directory ID) for this cache of data

May 29 2015

Comments

Prepared by Sapient for Medtronic

Page 16

SST Core Data Cache Queue

Response Data GET Core Data Cache

This is the container for all of the response parts that match one for one the components of the
request. The response includes the data delivered in a stream what is missing?
For a response code 200 OK:

Request Attribute

Data
Type

Description

dataBytes

Bytes

In 2nd part of multi-part request.

May 29 2015

Comments

Prepared by Sapient for Medtronic

Page 17

SST Core Data Cache Queue

May 29 2015

Prepared by Sapient for Medtronic

Page 18

SST Core Data Cache Queue

4.5

Process Flow Exception Scenario(s)

404 NOT FOUND If no CD file is available for the user passed in with the GET request, the
hybris server should return a 404. In this scenario, the mobile client will initiate a GET to the Sync
endpoint, to request a full sync.

See ISD_REST_Response_Exception_Handling.docx

May 29 2015

Prepared by Sapient for Medtronic

Page 19

SST Core Data Cache Queue

Exception Handling Strategy

REST Services exception handling would be based on existing hybris OOB REST exception framework.
The base controller
com.medtronic.b2b.commercewebservices.v1.controller.BaseController shows the exact
usage and need to be enhanced to accommodate BusinessException and
SystemExceptions.

May 29 2015

Prepared by Sapient for Medtronic

Page 20

SST Core Data Cache Queue

Logging Strategy & Design

Please refer to section 7.3 in platform design document

(https://del.sapient.resultspace.com/scm/medtronic/trunk/Analysis_Design/Component_Design/Pl
atform/Medtronic_Platform_Design.docx)

May 29 2015

Prepared by Sapient for Medtronic

Page 21

SST Core Data Cache Queue

Document References

List any relevant reference documents.

Document Name

Description

Location

High level integration architecture as

High Level Integration
discussed and designed with
Diagram
Medtronic IT team
Non-FunctionalNon-functional requirements as discussed
Requirements
and defined with Medtronic
???

May 29 2015

Prepared by Sapient for Medtronic

Page 22

SST Core Data Cache Queue

May 29 2015

Prepared by Sapient for Medtronic

Page 23

SST Core Data Cache Queue

May 29 2015

Prepared by Sapient for Medtronic

Page 24