ISD CoreDataCache

Interface Specification: User Management

SST Core Data Cache Queue

Medtronic REST Integration Specification 10 Nov. 2014

REST Integration SpecificationMedtronic SST Core Data CacheNov 18, 2014

Sapient

Table of Contents1Overview41.1Purpose41.2Audience41.3Glossary of Terms42SST Core Data Cache Queue52.1Assumptions52.2Approach52.3Process Flow -- POST52.3.1Process Flow - Request Data (multi-part request: meta data followed by the Core Data file)62.3.2Response Data POST Core Data Cache62.4Process Flow -- GET72.4.1Process Flow - GET Request Data72.4.1Response Data GET Core Data Cache72.5Process Flow Exception Scenario(s)73Exception Handling Strategy84Logging Strategy & Design95Document References10

Table of Contents

Copyright 2015 Sapient Corporation | Confidential

February 06 2015 PREPARED BY SAPIENT FOR Medtronic | CONFIDENTIALiiRevision History

DateVersionDescriptionAuthor

28-Oct-20140.1Initial Draft- TemplateSapient Nitro

18-Nov-20140.2DraftRP Nelson - MDT

23-dec-20140.3Daily updates of core data cache file desired.RP Nelson

03-Feb-20150.4Updated to match modified sync design, services, added flow diagram, consolidated the two Core Data Cache ISDsP. Ericksen - MDT

1. OverviewPurposeThis document captures the REST integration requirement, design and approach for Medtronic ecommerce platform.AudienceThe different groups of audience members to which this document applies to are:a) Medtronic IT Team.b) Sapient Development Teamc) Sapient & Medtronic QA TeamsGlossary of Terms

TermMeaning

GCSSPGlobal Customer Self Service Portal

SSTSpine Sales Tool

CDCore Data

1 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: /api/v1/cache. For example, the SST mock services endpoint is: https://entmobt.medtronic.com/api/v1/cache

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.

Approacha) 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.

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 database9. 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).

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

Request Attribute DataTypeDescriptionComments

sessionTokenStringHttp cookie from authentication.

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

idStringGUID of work queue item.

createDateTimeUnix Date

userIdStringUser to which this core data cache belongs.

queueIdStringThe unique identifier for the work item that this core data file representsused by server to change status on the work queue

dataBytesBytesIn 2nd part of multi-part request.

1.1.2 Response Data POST Core Data Cache

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

Process Flow -- GET

1.1.3 Process Flow - GET Request Data


sessionTokenStringHttp cookie from authentication.

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

useridStringSST user id (MDT enterprise directory ID) for this cache of data

1. 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:


dataBytesBytesIn 2nd part of multi-part request.

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

2 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.

3 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/Platform/Medtronic_Platform_Design.docx)

4 Document ReferencesList any relevant reference documents.Document NameDescriptionLocation

High Level Integration DiagramHigh level integration architecture as discussed and designed with Medtronic IT team

Non-Functional RequirementsNon-functional requirements as discussed and defined with Medtronic

???

Prepared by Sapient for MedtronicFebruary 06 2015Page 5

Documents

ISD CoreDataCache