NGPP Modernization RFQ

Project overview

NextGen Provisioning Platform (NGPP) is the Wireline Provisioning system that orchestrates and
activates on the network all cable services for Rogers customers. It consists of 3 Oracle Communications
solutions: Order Service Management (OSM), Unified Inventory Management (UIM), Automated Service
Activation Platform (ASAP) and one custom JEE solution: Rogers Web Services (RWS).

All 4 applications will be migrated from the current Solaris OS on Oracle SuperCluster M8 hardware to
Red Hat Enterprise Linux on private cloud virtual machines.

Requirements

There will be 14 environments in total: 5 Development (DEV), 4 Quality Assurance (QA), 1 Training (TRN),
1 Performance Testing (PET), 1 User Acceptance Testing (UAT), 1 Production (PROD), 1 Disaster Recovery
(DR).
Each of the environments will have all 4 applications installed and integrated: OSM, UIM, ASAP, RWS.
Each of PROD/DR/PET environments will have the following:

 1 WebLogic domain containing 10 WebLogic managed servers for OSM. Hosted on 5 separate
VMs, 2 managed servers per VM.
 1 WebLogic domain 8 WebLogic managed servers for UIM. Hosted on 4 separate VMs, 2
managed servers per VM.
 3 WebLogic domains each containing 1 managed server for ASAP. Hosted on 3 separate VMs, 1
managed server per VM.
 1 WebLogic domain containing 4 WebLogic managed servers for RWS. Hosted on 2 separate
VMs, 2 managed servers per VM.

DEV (5 separate environments):

 1 WebLogic domain containing 1 WebLogic managed server for each of OSM, UIM, ASAP, RWS.

QA (4 separate environments):

 1 WebLogic domain containing 2 WebLogic managed servers for each of OSM, UIM, RWS.
 1 WebLogic domain containing 1 WebLogic managed server for ASAP.

TRN (1 environment):

 1 WebLogic domain containing 2 WebLogic managed servers for each of OSM, UIM, RWS.
 1 WebLogic domain containing 1 WebLogic managed server for ASAP.

UAT (1 environment):

 1 WebLogic domain containing 4 WebLogic managed servers for each of OSM, UIM, RWS.
  3 WebLogic domains, each containing 1 WebLogic managed server for ASAP.

On each VM for OSM app, perform the following:

1. Install JDK (e.g. JDK 8 update 411).

2. Install Oracle Fusion Middleware 12.2.1.4.
3. Patch Middleware to the latest Critical Patch Updates and Overlay Patches.
4. Install OSM 7.5 including any pre-requisite libraries.
5. Create and configure all WebLogic items that exist in the corresponding current environment,
like distributed queues, data sources, destination keys, topics, bridges, store-and-forward agents,
SSL certificates, etc. All WebLogic configuration settings should be exactly matched to the
corresponding current environment. E.g. new DEV WebLogic domains should have the same
settings in config.xml as the existing DEV domains.
6. Compile the current cartridge code base with OSM SDK 7.5 and make any required code changes
in Design Studio related to the version upgrade. Ensure proper build in Design Studio on a local
machine and commit the updated code to Git. Work with Rogers build team to update the
headless server build in UCB (IBM Urban Code Build).
7. Configure proper deployment from both Design Studio on a local machine and a headless server
deploy by UCD (IBM Urban Code Deploy).
8. Configure OSM users and workgroups, as per existing environments.
9. Configure WebLogic AD integration (new WebLogic Authentication Provider in Security Realms).
10. Deploy the custom JEE application interacting with OSM (e.g. Rogers OrderManagement) in the
same WebLogic domain.
11. Send a sample OSM xml request and confirm the OSM order is created.
12. After the remaining applications are installed, ensure the integrations are functional, e.g. OSM
can send request/response to/from UIM; OSM can send request/response to/from ASAP; OSM
can receive request/response to/from upstream ordering system (Maestro); integrations
between OSM and various Rogers middleware systems (e.g. RESP-ESB, SSG, Kafka).

On each VM for UIM app, perform the following:

1. Install JDK (e.g. JDK 8 update 411).

2. Install Oracle Fusion Middleware 12.2.1.4.
3. Patch Middleware to the latest Critical Patch Updates and Overlay Patches.
4. Install UIM 7.6 including any pre-requisite libraries.
5. Create and configure all WebLogic items that exist in the corresponding current environment,
like distributed queues, data sources, destination keys, topics, bridges, store-and-forward agents,
SSL certificates, etc. All WebLogic configuration settings should be exactly matched to the
corresponding current environment. E.g. new DEV WebLogic domains should have the same
settings in config.xml as the existing DEV domains.
6. Compile the current cartridge code base with UIM SDK 7.6 and make any required code changes
in Design Studio related to the version upgrade. Ensure proper build in Design Studio on a local
 machine and commit the updated code to Git. Work with Rogers build team to update the
headless server build in UCB (IBM Urban Code Build).
7. Configure proper deployment from both Design Studio on a local machine and a headless server
deploy by UCD (IBM Urban Code Deploy).
8. Configure UIM users as per existing environments.
9. Configure WebLogic AD integration (new WebLogic Authentication Provider in Security Realms).
10. Deploy the custom UIM webservices and any required rulesets.
11. Send a sample Business Interaction xml request and confirm proper responses from UIM.
12. After the remaining applications are installed, ensure the integrations are functional, e.g. UIM
can receive requests and send responses to OSM; requests to the custom webservices are
returning proper responses.

On each VM for ASAP app, perform the following:

1. Install JDK (e.g. JDK 8 update 411).

2. Install Oracle Fusion Middleware 12.2.1.4.
3. Patch Middleware to the latest Critical Patch Updates and Overlay Patches.
4. Install ASAP 7.4 including any pre-requisite libraries. Note: PROD, DR, PET, UAT environments will
have Order Balancer components installed, i.e. 1 VM in each of those environments will not have
full ASAP install but only the Order Balancer component in WebLogic domain. This is required to
achieve Active-Active configuration and zero-downtime deployment in ASAP.
DEV, QA, TRN environments will not have an Order Balancer (and no dedicated VM for this Order
Balancer).
5. Create and configure all WebLogic items that exist in the corresponding current environment,
like distributed queues, data sources, destination keys, topics, bridges, store-and-forward agents,
SSL certificates, etc. All WebLogic configuration settings should be exactly matched to the
corresponding current environment. E.g. new DEV WebLogic domains should have the same
settings in config.xml as the existing DEV domains. Make sure any non-default configuration
settings for the native components in ASAP.cfg that exist in the environment environments, are
applied.
6. Compile the current cartridge code base with ASAP SDK 7.4 and make any required code changes
in Design Studio related to the version upgrade. Ensure proper build in Design Studio on a local
machine and commit the updated code to Git. Work with Rogers build team to update the
headless server build in UCB (IBM Urban Code Build).
7. Configure proper deployment from both Design Studio on a local machine and a headless server
deploy by UCD (IBM Urban Code Deploy). Ensure all existing Network Elements are correctly
deployed.
8. Configure ASAP users as per existing environments.
9. Configure WebLogic AD integration (new WebLogic Authentication Provider in Security Realms).
10. Customize ASAP.ear to redirect responses to OSM over a JMS queue instead of a topic.
11. Confirm OCA clients runs properly and can successfully search for existing orders.
12. After the remaining applications are installed, ensure the integrations are functional, e.g. ASAP
can receive requests and send responses to OSM.
On each VM for RWS app, perform the following:

1. Install JDK (e.g. JDK 8 update 411).

2. Install Oracle Fusion Middleware 12.2.1.4.
3. Patch Middleware to the latest Critical Patch Updates and Overlay Patches.
4. Create and configure all WebLogic items that exist in the corresponding current WebLogic
domain, like distributed queues, data sources, destination keys, topics, bridges, store-and-
forward agents, SSL certificates, etc. All WebLogic configuration settings should be exactly
matched to the corresponding current environment. E.g. new DEV WebLogic domains should
have the same settings in config.xml as in the existing DEV domains.
5. Configure WebLogic users, as per existing environments.
6. Configure WebLogic AD integration (new WebLogic Authentication Provider in Security Realms).
7. Deploy the custom JEE applications – RWS.ear and NGPPAPIGW.ear.
8. Send sample xml requests and confirm the webservices are returning correct responses.

Migration

Infra implementation is side-by-side (brand new VMs and DBs for each application). Since this is not an
in-place upgrade, the vendor should design and implement a data migration strategy for OSM in-
progress orders and the entire UIM data set. OSM orders that are already completed don’t need to be
migrated. No ASAP data migration is needed since there are no long running orders (ASAP orders close
under 30-60 seconds on average). There is no explicit requirement from Rogers for a transition
architecture if “all at once” cutover is feasible.

Sanity Testing

A basic sanity testing is required from the Vendor after each environment is integrated (both internally
within NGPP applications, and with external systems), before the environment is released to Rogers
testing team. The goal is to ensure all cartridges are deployed and all integrations are functioning. This
can be done by sending Triple Play Provide orders (HSI+IPTV+RHP) with both Immediate and Tech
options. Functional testing will be performed entirely by Rogers team.

Performance Testing

The latest application versions (OSM, UIM, ASAP) should maintain the same performance as the current
ones. In case the current benchmarks are not met, a performance tuning will be required and will be in-
scope for Vendor. Performance testing will be done entirely by Rogers team.

Support

- Support ORT exercises (up to 3), typically done outside business hours.
- Support PROD/DR environments for 6 weeks after cutover date.
For all the 4 applications:

1. Due to aggressive project timeline, commence scripting of WebLogic/applications installation

and configuration (with Ansible or similar tool) on vendor own infra with same target OS, in
advance of new VMs being created on Rogers Infra. The number of environments and VMs per
environment is high and therefore requires an automated (not manual) installation and
configuration process.
2. Vendor will develop scripts to ingest all config parameters from current existing WebLogic
environment and recreate the exact same values on the newly created WebLogic domains, for all
applicable objects like distributed queues, data sources, store-and-forward agents, server
startup arguments, etc.
3. Create detailed documentation for all new environments, including but not limited to application
endpoints, installation locations on disk, app usernames and passwords, applied patches, etc.
4. Request from Rogers Infra teams and track config changes required by Oracle applications as per
the install documentation, e.g. OS kernel parameters or database init parameters.
5. Provide support during the entire project timeline, from initial install on DEV environments to
actual Production implementation, including multiple ORT exercises (Operational Readiness
Testing) and trial DR switchovers.
6. Create a plan for, test, and execute application data migration. E.g. existing OSM order data on
7.3.5 version migration to the new 7.5 database schema.
7. Triage, debug, and resolve issues that arise from application version upgrade (e.g. codebase on
OSM SDK 7.3.5 to OSM SDK 7.5) or from OS change (e.g. Solaris 11.4 to RHEL 9). Issues can
emerge during application install, QA testing cycle, or during performance testing cycle.
8. When required, open SR (Service Request) with Oracle Support for the corresponding
application (OSM, UIM, ASAP, or WebLogic) and keep updating the ticket to successful
completion.
9. Resolve any net new security issues flagged by SonarQube and JFrog Xray scanning tools, related
to application upgrade. Solution could necessitate either a code fix or an application library
update. Assist Rogers teams to address any issues resulting from CyberStarr security review.

Out of scope:

1. Database server installation and configuration.

2. Linux VM installation and OS level patching.
3. Creating firewall requests for endpoints outside of the application network
4. Software licenses.

Current implementation details

OSM

OSM 7.3.5, deployed in WebLogic 12.2.1.4, JDK 8, on Solaris 11.4

14 Solution cartridges. Out of those 14, 4 are RSDOD (SNO). 128 Component cartridges.
Oracle SNO framework is used in the main RSDOD solution (both OSM and UIM)

UIM

UIM 7.4.1, deployed in WebLogic 12.2.1.4, JDK 8, on Solaris 11.4

24 cartridges. Out of those 24, 12 are the custom solution code.

Oracle SNO framework is used in the main RSDOD solution (both OSM and UIM)

ASAP

ASAP 7.3, deployed in WebLogic 12.2.1.3, JDK 8, on Solaris 11.4

14 Network Elements (Interface types: SOAP webservice, RESTful webservice, TCP, SSH)

26 Service and Network cartridges.

RWS

Custom JEE, deployed in WebLogic 12.2.1.3, JDK 8, on Solaris 11.4

2 app files - RWS.ear and NGPPAPIGW.ear