There are several common questions that will help you clarify the process for this process.

No, this capability is designed for existing Oracle Utilities Customer Care and Billing and Oracle Utilities Customer to Meter on-premises implementations to migrate to the cloud quickly. It will not be extended past that scenario.

With each upload you should specify a code identifier to identify the code you are uploading for each step. This can be any valid release identifier applicable to the developer or code being uploaded. The format of the identifier must only include alphanumeric, underscores, and dashes. Spaces and special characters are not supported as part of identifiers.

The process has been designed to assess the custom Java source code and custom tables against standards outlined in the Oracle Utilities SDK and cloud service standards to ensure compliance with the cloud and help ensure high levels of security are maintained. If there is non-compliance detected this will be reported by the various utilities and the suspect code is not implemented. It is recommended to re-mediate the code at the source and re-upload the source for reassessment till it is fully compliant.

No, the design of the capability is to quickly migrate to the cloud, maintain your existing extensions, and then use the cloud facilities for new extensions going forward to retain and maximize cost benefits of moving to the cloud.

Yes, the service architecture has been designed to isolate extensions to a different but integrated part of the architecture for security isolation and prevent instability. The architecture uses the cloud infrastructure to provide sufficient access to the extensions that is transparent to the extension but allow the service to fully use the extensions. It combines good security practices while supporting extensions.

The main reason that the Oracle Utilities Cloud Services save costs is that there are inbuilt capabilities that replace work that was traditionally done on-premises. There are prebuilt and transparent configurations for the architecture that run the service and your extensions seamlessly. In those cases, operational based extensions are not needed as part of the transition and included as part of the service.

The PRIVILEGED threadpool is a special threadpool optimized for processing Java code for deployment. This process is design only to run in this threadpool and this threadpool has been designed only for this process. It is highly recommended not to run any other process in this special threadpool as it is not designed for other processes and may cause failures.

The migration and maintenance processing has been designed to be as close as the same process as you are familiar for on-premises but take advantage of the cloud infrastructure. It provides flexibility, traceability, and efficiency in deploying custom java and custom tables reducing outage time, if needed. The multi-step process allows partners and customers assess and react to changes as they are being implemented.

Yes, the process has been designed to be flexible enough for multiple developers to upload and add their changes to the service via the Adhoc Generation Request stage. Each developer should use a unique code identifier to delineate code. Each change is cumulative and added to the deployment as necessary. Overlaps in the scope of code identifiers will result in replacing overlaps with the latest upload. Only one developer should run Code Deployment Request to assemble the deployment.