Sneaker store
Solution Development Case Study
Shooster Shooster
ABOUT PROJECT, and are clients applications of our CoreAPI service that separates all business and data access logic into separate modules. For Shooster we developed responsive web (where white labeled solution is used on Noss website), currently we are developing responsive CoreAPI web application for new sales channel - Timberland, base od interactive wireframes sent by the Client.
- Single entry point for all communications with the Tomsoft Luceed ERP system of the Client. All functionality and integration points are always available to all sales channels (Shooster, Noss, Timberland), with custom configuration
- Application uses one database and one cache depository for all of the client applications, and white labeled sales channels ensure that all changes are propagated through the system from the ERP in real time - the goal of this model is to provide a real-time system status (warehouse status, availability, customer data and transactions), as well as reducing the resources needed for the operational work of the future client (web or mobile) applications
- Application allows some independence for the client applications, in terms of the development of the user interface, but it is centralizing all critical logic in terms of uniform expected system behavior for all business scenarios
Considering the specific implementation needs for the ERP software used by the Client, as well as the need for further development of web applications that are related to the introduction of new sales channels and markets (website for each sales channel to other domains / languages), we have developed a CoreAPI application that has two main objectives:
- centralization of the business logic
- separation of the business logic from the presentation of the sales channels and/or markets

All the processes are adapted to "Pipeline" model. Pipeline operating model specified process involves abstraction of each process in relation to a particular sales channel:
- the process of dividing the processing modules that have an execution sequence and the starting point (entry point) for the whole process or phase of the process in case of discontinuity
- Business logic for the modules is separated completely from the sales channel and it’s being used with the sales channel based on defined configuration:
    - configuration in terms of use and/or use of repetition processing modules and their arrangement within the process
    - configuration of each module in terms of specificity for a particular sales channel if needed
This model of business logic enables centralized deployment and flexibility.

Each sales channel can be managed, upgraded and can modify its business logic if needed, without affecting other sales channels and their processes.