Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ti-infinite/GSMApplication/llms.txt

Use this file to discover all available pages before exploring further.

GSMApplication is the configuration and presentation layer of the GSM Application platform. It is responsible for providing each authenticated user with the correct navigation menu for their profile, serving multimedia resources to the UI, managing user password updates, and maintaining the per-tenant API rule definitions that drive the integration engine in GSMOperations. Because this service operates within the multi-tenant architecture, every request resolves its tenant database via the X-Company-Id header injected by the gateway before any data is read or written.

​
Layer Structure

GSMApplication.Api

HTTP controllers: ApplicationController, UsersController, and IntegrationsController.

GSMApplication.Business

Service implementations for menu retrieval, multimedia lookup, user management, and API rule CRUD.

GSMApplication.Abstractions

Interfaces that decouple controller logic from business implementations via dependency inversion.

GSMApplication.Entities

DTOs: GetMenuDto, MultimediaResourceDto, ApiRuleDTO, UpdateUserPasswordDTO, and shared response wrappers.

GSMApplication.DataAccess

EF Core contexts for the registry database and the dynamic tenant database.

GSMApplication.Infrastructure

Concrete repository implementations and cross-cutting infrastructure concerns.

GSMApplication.Tenant

TenantContext and tenant middleware. Reads X-Company-Id from gateway-forwarded headers, with a JWT-claim fallback for local development.
The service listens on port 8082 and is reached through the gateway at the /api/application/** prefix.

​
Endpoints

​
GET /api/v1/application/getMenu

Returns the navigation menu tree for the authenticated user’s profile. This endpoint requires a valid Bearer token. The profile identifier is read from the X-Profile-Id request header, which the gateway injects from the JWT’s idProfile claim before forwarding the request. Request: No body. The Authorization: Bearer header is required. Response:
​
idProfile
integer | null
The numeric profile identifier associated with the returned menu definition.
​
menu
string
The serialized menu structure for the profile. Deserialize this on the client to build the navigation tree.
Status codes:
StatusCondition
200 OKProfile resolved successfully; menu returned.
401 UnauthorizedBearer token is missing, expired, or does not carry a resolvable idProfile claim.

​
GET /api/v1/application/getMediaResources

Returns a list of multimedia resources filtered by one or more category names. Used by the front end to load images, videos, or configuration blobs associated with specific UI sections. Query parameters:
​
categories
string[]
required
One or more resource category identifiers. Passed as repeated query string parameters, e.g. ?categories=hero&categories=banner. At least one value is required; an empty list returns a 400 Validation error.
Response item shape:
​
resourceCategory
string
The category string that this resource belongs to.
​
resourceOrder
integer
Sort order within the category. Lower values appear first.
​
config
string
A JSON or plain-text configuration payload specific to the resource (e.g. URL, alt text, display options).

​
PUT /api/v1/users/{idUser}/password

Updates the password for a specific user in the tenant database. The caller supplies the current password for verification and the desired new password; the service handles hashing internally.
​
idUser
guid
required
The IdUser GUID of the user whose password is being updated.
​
OldPassword
string
required
The user’s current plaintext password. Used to verify identity before the update is applied.
​
NewPassword
string
required
The new plaintext password to set. The service hashes this value before persisting it.

​
GET /api/v1/integrations/api-rules

Returns all API rule records defined for the current tenant.

​
GET /api/v1/integrations/api-rules/{idApiRule}

Returns a single API rule by its integer identifier.
​
idApiRule
integer
required
Primary key of the ApiRule record.

​
POST /api/v1/integrations/api-rules

Creates a new API rule for the current tenant.
​
shortName
string
required
A brief, unique identifier for the rule used when executing it from GSMOperations.
​
descr
string
Optional human-readable description of what the rule does.
​
urlEndPoint
string
required
The target endpoint URL that the integration engine will call when the rule is executed.
​
operation
string
required
The HTTP method or operation type that the rule executes (e.g. GET, POST).

​
PUT /api/v1/integrations/api-rules/{idApiRule}

Updates an existing API rule.
​
idApiRule
integer
required
The ID of the rule to update.
The body shape is identical to the POST endpoint above.

​
DELETE /api/v1/integrations/api-rules/{idApiRule}

Permanently removes an API rule from the tenant database.
​
idApiRule
integer
required
The ID of the rule to delete.

​
API Rules

API rules are tenant-scoped configuration records that store the target URL and HTTP method for each named integration. Each rule carries a ShortName for human identification, a UrlEndPoint, and an Operation type. The frontend retrieves a rule’s UrlEndPoint and Operation values from this service, then passes them directly to GSMOperations /api/v1/integrations/exec-api to trigger the outbound call. Rules are managed exclusively through GSMApplication — the two services together form the configurable integration pipeline. 
public sealed class ApiRuleDTO
{
    public required string ShortName   { get; set; }
    public          string? Descr      { get; set; }
    public required string UrlEndPoint { get; set; }
    public required string Operation   { get; set; }
}

​
Multi-Tenant Behavior

Every request to GSMApplication resolves its tenant before executing any business logic:
1

Header read

The TenantMiddleware reads X-Company-Id from the incoming request headers. This header is injected by the gateway from the validated JWT’s companyId claim.
2

JWT fallback (development only)

If X-Company-Id is absent (direct service call in a local environment), the middleware falls back to reading the companyId claim from the Bearer JWT. This fallback is not available in production where all traffic flows through the gateway.
3

Dynamic DbContext

TenantContext.CompanyId is populated and the per-request EF Core DbContext is constructed against the tenant’s isolated SQL Server database.
The getMenu endpoint reads idProfile from the X-Profile-Id header (also injected by the gateway) rather than making an additional database call, keeping menu resolution fast and allocation-free.

Build docs developers (and LLMs) love

Get started for freeTalk to us