ShowMgr connects production planning, scheduling, resource management, financial tracking and reporting through shared application services and records. Each module provides a different way to manage and view that information.
Application layers
| Layer | Responsibility | Technology |
|---|---|---|
| Browser application | Displays modules, searches, forms, schedules and worksheets | Ext JS and ASP.NET |
| Application API | Receives requests from the product and directs them to application services | C# ASP.NET Web API |
| Application services | Coordinate workflow operations and apply user and client context | Shared C# services |
| Data access | Reads and updates persistent records | Entity Framework, SQL Server commands and stored procedures |
| Reporting | Applies report definitions and parameters to produce output | Telerik reporting and shared report services |
| Supporting services | Store files, cache selected results and process notification requests | Object storage, Redis and Amazon SQS |
| Component | Connects to / uses | Relationship |
|---|---|---|
| Browser application | Application API | Application requests |
| External integrations | External API | Integration requests |
| Both API layers | Shared services | Workflow operations |
| Shared services | Data access | Record retrieval and changes |
| Data access | SQL records and routines | Persistence and database logic |
| Relevant service paths | Reports, file/cache services and queued notifications | Supporting operations; not a server map |
These layers describe responsibilities within the application. A module is a functional area, such as scheduling or invoicing; it does not represent a dedicated server or database.
How a request moves through ShowMgr
A browser request reaches an API controller, which calls the appropriate application service. The service coordinates the operation and accesses records through the data access layer. Database work uses Entity Framework queries and updates, SQL commands, or stored procedures, depending on the operation.
The response returns the information needed to update the screen. A booking response, for example, can include the booking's element, order information, dates, status and financial values.
Shared context connects the modules
Application services carry the client, user, access levels, linked resource, default system division and time-zone context. The same context supports related work across orders, bookings, actuals and other modules.
Client configuration determines available classes, fields, statuses and navigation. User permissions determine which records and actions the user can access. Together, these settings explain differences between users working in the same module.
Supporting systems handle different work
Report rendering uses Telerik reporting and Redis-backed report storage. Document retrieval supports Amazon S3 and Azure Blob Storage. Selected booking alerts and push-notification requests are submitted through Amazon SQS for processing.
Saving an operational record, rendering a report, retrieving a document and delivering a notification are separate operations. An order can remain available while a report fails to render. A booking can be saved before its notification reaches the recipient.
When troubleshooting, identify the operation that failed and its dependencies: the operational record, report definition and parameters, document content, or notification processing path.