Source: projects/identity-management/knowledge-base/oim-web-portal-api-server-project.md

> Source: projects/identity-management/knowledge-base/oim-web-portal-api-server-project.md

OIM Web Portal and API Server Project Knowledge Base

Scope

This note summarizes the sandbox Web Portal/API Server project discovered at C:\Dev\IdentityManager.Imx, and correlates it with the existing sandbox DB and decompiled object-layer research.

The project is an Angular/Nx frontend workspace for One Identity Manager 10.0 Web Portal-style applications. The backend API Server itself is not implemented in this source tree; the frontend consumes https://im.sandbox.local/ApiServer through generated OneIM API clients.

Primary Sources

Workspace Shape

C:\Dev\IdentityManager.Imx\imxweb is an Angular 20/Nx 21 workspace named imxweb with package version 10.0.0.

Main applications:

Main libraries:

The frontend uses generated API packages such as @imx-modules/imx-api-qbm and @imx-modules/imx-api-qer. These are the main bridge from Angular components/services to API Server endpoints.

Runtime Bootstrap

The Web Portal app configuration sets:

The environment files point the portal to:

The frontend startup path is:

1. qer-app-portal/src/app/app.service.ts reads the environment and initializes common services.

2. qbm/src/lib/appConfig/appConfig.service.ts loads appconfig.json, creates the base QBM V2Client and ApiClient, and loads API schema metadata.

3. qer/src/lib/qer-api-client.service.ts lazily creates the QER V2Client and typed client using the QBM schema provider and API client.

4. Feature services call generated typed endpoints or lower-level client.* methods.

The important architectural point is that the frontend is schema/API driven. It does not encode SQL behavior directly. Database writes and workflow actions are mediated by API Server and the OneIM object layer.

Web Portal Functional Areas

The portal README and app module show these major user-facing areas:

qer-app-portal/src/app/app.module.ts wires the app by importing many QBM/QER modules, including NewRequestModule, ProductSelectionModule, ShoppingCartModule, ApprovalsModule, RequestHistoryModule, ArchivedRequestsModule, ServiceCategoriesModule, ServiceItemsEditModule, ItshopPatternModule, MyResponsibilitiesViewModule, DataExplorerViewModule, and QueueStatusComponent.

IT Shop Frontend Flow

The IT Shop documentation under projects\qer\additionalDocumentation\it-shop.md describes the request path as:

1. NewRequestComponent starts the request lifecycle.

2. Product discovery is split across:

3. Request parameters are transformed by ParameterDataService and edited by CartItemEditComponent.

4. ShoppingCartComponent lets the user validate, edit, delete, save for later, and submit cart items.

5. ApprovalsComponent and InquiriesComponent handle approval and inquiry work.

6. RequestHistoryComponent plus RequestActionService handles request history and user actions.

7. ArchivedRequestsComponent shows archived request data.

8. Setup/admin views edit product bundles, service categories, and service items.

API Endpoint Surface Observed in the Frontend

Important IT Shop and request endpoints surfaced by frontend services:

Other portal areas use endpoints such as portal_hyperview_get, portal_statistics_*, PortalSysteminfoThirdparty.Get, and PasswordresetSysteminfoThirdparty.Get.

Correlation to DB Tables

The frontend endpoint names are portal API abstractions, not direct SQL table names. The underlying OneIM concepts still map to familiar database objects.

Observed likely correlations:

Portal / API conceptDB / object-layer conceptEvidence level
PortalShopServiceitemsrequestable service items, mainly AccProduct plus category and IT Shop visibility contextstrong frontend + DB concept match
service category UIAccProductGroupstrong
service item editorAccProductstrong
product/shop/bundle setupITShopOrg, ITShopInfo, BaseTree, BaseTreeHasObject, entitlement link views/tablesstrong from DB evidence
cart itemshopping cart item/request staging, then request workflow; likely ShoppingCartOrder and PersonWantsOrg during submitmedium; API abstraction requires backend endpoint trace for exact write sequence
approval requestPersonWantsOrg request approval statestrong from frontend method names and decompiled customizer methods
attestation approval modulesAttestationCase and AttestationPolicystrong from DB/decompile evidence

Live API evidence now upgrades the cart-submit row from medium to strong:

The existing DB evidence shows that IT Shop availability and product publication still depend on DB structure:

Correlation to Object-Layer Methods and Events

The approval endpoint names closely match decompiled PersonWantsOrg customizer methods. This is the most important relationship between the Web Portal and the previously decompiled project.

Web Portal/API actionDecompiled/customizer method correlation
portal_itshop_decide_postPersonWantsOrg.MakeDecision
portal_itshop_escalate_postPersonWantsOrg.Escalate / DB event spelling ESCALATE
portal_itshop_denydecision_postPersonWantsOrg.DenyDecision
portal_itshop_directdecision_postPersonWantsOrg.DirectDecision
portal_itshop_additional_postPersonWantsOrg.AddAdditional
portal_itshop_revokeadditional_postPersonWantsOrg.RevokeAdditional
portal_itshop_insteadof_postPersonWantsOrg.AddInsteadOf
portal_itshop_revokedelegation_postPersonWantsOrg.RevokeDelegation
portal_itshop_query_postPersonWantsOrg.QueryToPerson
portal_itshop_answerquery_postPersonWantsOrg.AnswerFromPerson
portal_itshop_recalldecision_postPersonWantsOrg.RecallDecision
portal_itshop_recallquery_postPersonWantsOrg.RecallQuery
portal_itshop_resetreservation_postPersonWantsOrg.ResetReservation
portal_cart_submit_postOrderShoppingCart

The decompile index also found other PersonWantsOrg methods relevant to request state changes:

For IT Shop structure administration, decompiled ITShopOrg methods include:

These methods are gated by ITShopInfo semantics and should not be treated as generic row updates.

Correlation to DBQueue and QBM_PJobCreate

The Web Portal calls API Server, not stored procedures directly. The stored procedure relationship appears one layer deeper:

1. Portal Angular service calls a generated API Server endpoint.

2. API Server uses generated schema/object-layer endpoints.

3. Object-layer methods and events apply request, approval, attestation, or IT Shop logic.

4. DB triggers/procedures enqueue DBQueue tasks or create jobs when asynchronous database or process work is required.

Existing research found:

For IT Shop request and approval workflows, the frontend endpoint names reinforce the previous conclusion: safe workflow execution should happen through API Server/object-layer methods or supported tools, not by directly mutating request-state columns in SQL.

The live cart-submit trace showed this concrete path:

Angular CartItemsService.submit()
  -> generated API method portal_cart_submit_post
  -> API Server /portal/cart/submit/{uidcart}
  -> object-layer cart submit behavior
  -> PersonWantsOrg insert
  -> DialogProcess rows by GenProcID
  -> JobQueue HandleObjectComponent/CallMethod

The trace also confirms that submit validation is enforced before request creation. A controlled attempt to submit Delete Active Directory group without its required Active Directory group to delete parameter returned HasInvalidParameters = true, HasErrors = true, and Submitted = false.

Practical Guidance

Use the Web Portal/API Server path for workflow actions:

Use DB structure knowledge for publication and diagnostics:

1. create/link AccProduct;

2. set ADSGroup.UID_AccProduct;

3. set ADSGroup.IsForITShop = 1;

4. assign the group to a BO shelf through the correct base-tree relation;

5. let ShoppingRack DBQueue create the PR product node.

Use the custom-app project as the safe starting point for custom frontend extensions:

Known Limits

Next Experiments