Source: projects/identity-management/oim-kb-update/sandbox-db/2026-04-27-webportal-cart-submit-snapshots.md

> Source: projects/identity-management/oim-kb-update/sandbox-db/2026-04-27-webportal-cart-submit-snapshots.md

Web Portal Cart Submit DB Snapshot Evidence

Scope

Controlled sandbox Web Portal API experiment to connect generated portal endpoints to object-layer request processing and DB/job side effects.

The mutation was performed through API Server, not direct SQL DML.

Raw JSON evidence:

projects/identity-management/oim-kb-update/sandbox-db/2026-04-27-webportal-cart-submit-result.json

API Flow

The successful evidence run used these API Server calls:

1. GET /imx/sessions/portal

2. POST /imx/login/portal?noxsrf=false

3. DELETE /portal/cartitem/eae5a7db-2cb7-4a83-b2b2-80311be93bb4

4. GET /portal/shop/serviceitems?PageSize=20

5. POST /portal/cartitem

6. POST /portal/cart/submit/a047ce52-cbf4-4a14-bffa-3fc8dd5d08a0 with { "Mode": 0 }

7. POST /portal/cart/submit/a047ce52-cbf4-4a14-bffa-3fc8dd5d08a0 with { "Mode": 2 }

The delete was cleanup for a prior controlled attempt against Delete Active Directory group, which correctly failed submit validation because the required parameter Active Directory group to delete was missing.

Successful Request

Field	Value
Authenticated identity	`ser_oim, OIMService`
Ordered product	`Teams channel for Starling Cloud Assistant recipient`
`UID_AccProduct`	`QER-96F8166E403E9448AD8F293BB15A6260`
`UID_ITShopOrg`	`QER-6DF4E012563B402891CB37A0A86915E6`
IT Shop path	`Identity & Access Lifecycle\Access Lifecycle\Add Teams channel to recipient`
`UID_ShoppingCartOrder`	`a047ce52-cbf4-4a14-bffa-3fc8dd5d08a0`
`UID_ShoppingCartItem`	`d3f6ac6e-d16f-4ec2-bbc4-4e154f753ea9`
Submit result	`Submitted = true`, no warnings, no errors
`UID_PersonWantsOrg`	`f70d4d0d-2f02-4c39-b157-260bc82c8748`
`PersonWantsOrg.OrderState` after submit	`OrderProduct`
`PersonWantsOrg.GenProcID`	`0d9a014b-30aa-4c21-bdaa-7b9fa589157a`
Immediate JobQueue component/task	`VI.JobService.JobComponents.HandleObjectComponent` / `CallMethod`

Before and After Snapshot Meaning

The snapshot query read these objects in a single unified result set before and after submit:

ShoppingCartOrder
ShoppingCartItem
PersonWantsOrg
DialogJournal
QBMDBQueueCurrent
JobQueue
DialogProcess

Before the successful submit, the active cart order a047ce52-cbf4-4a14-bffa-3fc8dd5d08a0 existed with CheckStatus = 0 after the prior failed parameterized cart item was deleted.

After submit:

ShoppingCartOrder.CheckStatus changed to 2.
The submitted ShoppingCartItem was deleted by the workflow after conversion into a request.
PersonWantsOrg row f70d4d0d-2f02-4c39-b157-260bc82c8748 was inserted for the Teams channel request.
The new PWO row received GenProcID = 0d9a014b-30aa-4c21-bdaa-7b9fa589157a.
DialogProcess recorded an insert process for the PersonWantsOrg object.
JobQueue received a HandleObjectComponent / CallMethod job with the same GenProcID.

Interpretation

The live trace confirms this processing path for a Web Portal IT Shop request:

Angular ShoppingCart / CartItemsService
  -> generated API method portal_cart_submit_post
  -> API Server endpoint /portal/cart/submit/{uidcart}
  -> object-layer cart submit behavior (correlates with OrderShoppingCart)
  -> ShoppingCartItem is consumed/deleted
  -> PersonWantsOrg request is inserted
  -> DialogProcess and JobQueue continue processing by GenProcID

This is stronger evidence than static endpoint names alone. The portal submit path is not a direct SQL insert into PersonWantsOrg; it runs through API Server/object-layer behavior and then produces DB/process side effects.

Related Observation: Parameterized Item Failure

The controlled Delete Active Directory group attempt produced:

HasInvalidParameters = true
HasErrors = true
Submitted = false
failed mandatory parameter check for Active Directory group to delete

This confirms that portal_cart_submit_post performs the same request validation checks seen in the Web Portal UI before creating/submitting the final request.