Search Results slot_type_service_id

Overview

AHM_SLOT_TYPE_SERVICES is a configuration table within the Oracle E-Business Suite Hosting Manager module (AHM). Its documented purpose is to hold the services that are available for a given slot type. In the hosting and service-fulfillment domain that AHM addresses, a slot type represents a definable unit of hosted capacity or a scheduling construct, and the services associated with that slot type describe the capabilities, offerings, or resources that can be provisioned or delivered against it. This table therefore functions as the association registry that binds service definitions to slot type definitions.

The ETRM metadata explicitly labels the product as "AHM - Hosting Manager (Obsolete)" and records the implementation status as "Not implemented in this database." This is a significant qualifier: in the Oracle EBS 12.1.1 and 12.2.2 environments referenced, the object is not physically present in the shipped database schema. References to it are therefore of interest primarily to legacy migration projects, historical data-model analysis, and documentation-driven research rather than to live operational querying. Any attempt to select from AHM_SLOT_TYPE_SERVICES in a standard environment will fail unless a custom or legacy implementation has created it.

Regarding Data Vault classification, the mined heuristic places this object as hub-leaning. In modeling terms, this suggests treating AHM_SLOT_TYPE_SERVICES as a hub entity keyed on its surrogate identifier, with the various mapping tables that reference it acting as link or satellite structures. This classification is a modeling suggestion derived from the foreign-key topology rather than a normative Oracle design statement.

Key Information Stored

The documented metadata identifies a small column set, centered on the primary key and the foreign-key-bearing business attributes.

• SLOT_TYPE_SERVICE_ID — The surrogate primary key, defined by the constraint AHM_SLOT_TYPE_SERVICES_PK. This is the unique system-generated identifier for each slot-type-to-service association row.
• SLOT_TYPE_ID — A documented column identifying the slot type to which the service association belongs. This is a business-key candidate and the principal join to the slot type definition entity.
• ONLINE_SERVICE_ID — A documented column identifying the online service being associated with the slot type. This is the second business-key candidate and supplies the service side of the relationship.

The combination of SLOT_TYPE_ID and ONLINE_SERVICE_ID constitutes the natural or business key of the association, while SLOT_TYPE_SERVICE_ID serves as the surrogate. The metadata records a second primary key constraint named ASTS_PK, which appears to be an alternate or duplicate key definition over the same identifying structure; the exact column composition beyond the surrogate is not fully itemized in the excerpt. Primary-key columns not otherwise itemized in the source metadata should be confirmed against the physical data dictionary before use.

Common Use Cases and Queries

The primary analytical use case is resolving which services are available for a given slot type — for example, supporting capacity planning, service catalog reporting, or reconciliation of legacy hosting configuration. A representative query pattern joins the association to its dependent mapping tables through SLOT_TYPE_SERVICE_ID:

• Lookup by slot type: select SLOT_TYPE_SERVICE_ID, ONLINE_SERVICE_ID from AHM_SLOT_TYPE_SERVICES where SLOT_TYPE_ID = :slot_type_id.
• Lookup by service: select SLOT_TYPE_ID from AHM_SLOT_TYPE_SERVICES where ONLINE_SERVICE_ID = :service_id.
• Role and group reporting: join AHM_SVC_ROLE_MAP and AHM_SVC_GROUP_MAP on SLOT_TYPE_SERVICE_ID to enumerate roles and service groups applicable to each slot type service.
• Response and application mapping: join AHM_SLOT_TYPE_SVC_RESP_MAP and AHM_SLOT_TYPE_SVC_IAPP_MAP on the same key column for responsibility and integrated-application visibility.

Because the object is documented as not implemented, these patterns apply to legacy or custom installations only. Migration scripts should treat the table as a source-to-target extraction exercise, validating that the surrogate keys remain consistent across the four dependent mapping tables to preserve referential integrity.

Related Objects

The metadata documents four dependent tables, each referencing AHM_SLOT_TYPE_SERVICES through the shared SLOT_TYPE_SERVICE_ID column. These constitute the most significant related objects:

• AHM_SLOT_TYPE_SVC_IAPP_MAP — maps slot type services to integrated applications, joined on AHM_SLOT_TYPE_SVC_IAPP_MAP.SLOT_TYPE_SERVICE_ID.
• AHM_SLOT_TYPE_SVC_RESP_MAP — maps slot type services to responsibilities, joined on AHM_SLOT_TYPE_SVC_RESP_MAP.SLOT_TYPE_SERVICE_ID.
• AHM_SVC_GROUP_MAP — maps slot type services to service groups, joined on AHM_SVC_GROUP_MAP.SLOT_TYPE_SERVICE_ID.
• AHM_SVC_ROLE_MAP — maps slot type services to roles, joined on AHM_SVC_ROLE_MAP.SLOT_TYPE_SERVICE_ID.

The typical join predicate across all four is mapping.SLOT_TYPE_SERVICE_ID = AHM_SLOT_TYPE_SERVICES.SLOT_TYPE_SERVICE_ID. The foreign keys run from the mapping tables to this hub table, confirming the hub-leaning classification. No views or APIs are documented for this object in the supplied metadata; any such artifacts would be legacy-specific and should be verified locally.