Challenge Overview
INTRODUCTION
This is the first in a series of challenges to replace ITI Order, the company’s primary internal and customer facing web based application. The primary function of the application is to manage the rental of medical devices to customers in acute care and home care settings. The first phase of development is focusing on the asset management portion of the system.
REQUIREMENTS
You’ll be designing the cloud based architecture that drives the data storage and retrieval for the web app. The backend should be Java based with MySQL as the storage engine. Data security should be a key concern and clearly reflected in architectural design.
The possibility exists for future expansion to native iOS and Android platforms, so consider those in your design as well. For the first phase the solution will be entirely based in a desktop web browser.
DATA OBJECTS
The following data objects will need to be captured as part of the system.
User: each user of the app will require an account (will be replaced in the future):
-- Username (email)
-- Password (hashed)
-- First Name
-- Last Name
-- System ID (alphanumeric id)
-- Status (active/inactive)
-- User roles (many possible)
-- Warehouse
-- Operations
-- Account Manager
-- Field Service Rep
-- Customer
Asset: an asset is the central object in the system:
-- Serial Number
-- Model
-- Revision
-- Branding
-- Cardinal Health
-- ITI
-- Status
-- In House
-- In Transit
-- Received
-- Cleaning
-- Repairing
-- Territory ID
-- Customer ID
-- Provisioning (changed from “Device Type”)
-- Rental
-- Eval
-- Demo
-- Owner
-- Date In Service
-- Hours in service
-- Date Retired
-- Comments
Inventory Transfer (renamed from “Shipment”): an inventory transfer is the movement of an asset from one location to another (may also be referred to as a “shipment”):
-- Assets (one per transaction)
-- Transaction Number (alphanumeric ID)
-- From Territory
-- To Territory
-- Shipment Method
-- Shipped By
-- Shipment Date
-- Expected Arrival Date
-- Received Date
-- Tracking Number
-- Comments (multiple possible)
-- Status
-- Draft
-- Shipped
-- Received
Inventory Transfer Request: a request for inventory to be shipped from the central warehouse:
-- Requesting User
-- Date
-- Time
-- Recipient First Name
-- Recipient Last Name
-- Recipient Email
-- Recipient Phone
-- Recipient Address (Lines 1 and 2)
-- Recipient City
-- Recipient State
-- Recipient Zip
-- Recipient Country
-- Item to Transfer (multiple possible)
-- Quantity to Transfer
-- Line Item Purpose
-- Rental
-- Eval
-- Demo
-- Instructions
-- Description
-- Status
-- Pending
-- Approved
-- Declined
Customer: a customer that will receive an asset (will be replaced in the future):
-- ID (incremental)
-- Customer Number (alphanumeric ID)
-- Name
-- Contact
-- Address
-- CIty
-- State
-- ZIp
-- Phone
-- Email
Territory: this is a warehouse where an asset would be stored:
-- ID (incremental)
-- Warehouse ID (alphanumeric)
-- City
-- State
-- Asset capacity
Lookups: these object should have ids, alphanumeric ids and descriptions:
-- User roles
-- Asset model
-- Asset revision
-- Asset branding
-- Asset status
-- Asset provisioning type
-- Inventory transfer request status
-- Inventory transfer status
-- Shipping method
Events: changes to key asset fields should be logged and stored for historical auditing purposes:
-- Territory change
-- Customer ID change
-- Status change
Special Notes
For the first phase of development, users will be stored/authenticated through this system. Future phases will incorporate enterprise SSO, so account for retrieving user data from LDAP in your architecture and consider the local user object as temporary.
As with users, customer data will be fed into the application via an external interface/API. Also account for this in your architecture and consider the local company object as temporary.
API ENDPOINTS
The following items are the minimum requirements for access via an API. Please feel free to include any additional items you feel may be useful in the architecture. Your API should be defined using the OpenAPI Specification.
-- Create/update user
-- Create/update customer - temporary functionality which will be replaced in the future with an external interface supplying customer data
-- Create/update asset
-- Create/update inventory transfer request
-- Create/update inventory transfer (a.k.a “shipment”)
-- Receive inventory transfer
-- Search assets (name, serial number, territory, shipped by, received date)
-- Search inventory transfers by attribute
-- Search customers by attribute
-- Search users by attribute
-- Lookups (search by description/name)
-- User
-- Asset model
-- Asset revision
-- Asset branding
-- Asset status
-- Asset provisioning type
-- Inventory transfer request status
-- Inventory transfer status
-- Shipping method
-- Territory
-- Customer
USER ROLES
The following user types and associated permissions need to be setup in the system. A single user may have multiple roles:
-- Warehouse
-- Shipping assets
-- Receiving assets
-- Updating assets
-- Operations
-- Shipping assets
-- Receiving assets
-- Updating assets
-- Adding assets
-- Approve inventory transfer
-- Account Manager / Field Service Rep (simplified as Rep)
-- Request inventory transfer
ADDITIONAL RESOURCES
Please reference the UI design challenge for additional information regarding the goals and functionality of the web app. See the Resources Repository for final designs and system design documentation. See the challenge forums for how to gain access to the GitLab group.
CLIENT PREFERENCES
The client has identified the following architecture preferences:
-- Web UI: HTML5/CSS/JS/Bootstrap
-- Web UI Testing: Selenium
-- Service Layer: Spring Boot/Spring MVC
-- App Container/Platform: Java/Pivotal Cloud Foundry/Tomcat
-- Java Unit Testing: Junit/Jaocco/Jmockit
-- Object Persistence: Spring Data JPA
-- Database: MySQL
-- Security: Spring Security/LDAP/SAML
-- Build: Gradle
Final Submission Guidelines
-- Document describing your architecture approach for the above requirements and how to deploy to the destination environment - AWS must be a deployment option
-- OpenAPI definition describing the endpoints for the above requirements
-- Architecture UML - use the Topcoder UML tool
-- Database ERD - preferred formats (in order) are PowerDesigner, ERwin, Visio and DML/DDL|
-- Additionally, the ERD should be able to be opened in MySQL Workbench