Pre-requisites: 1. ssl certificate 2. ssl certificate private key Pre-update: 1. Verify both ssl certificate and its private key:     1.1 Check the ssl certificate         #/> openssl x509 -in name_of_certificate_file.crt -text -noout     1.2 Check the private key         #/> openssl rsa -in name_of_private_key_file.key -check     1.3 Check the ssl certificate and private key pairing. The checksum (mdf5) output has to be indentical.                  #/> openssl x509 -noout -modulus -in name_of_certificate_file.crt | openssl md5         #/> openssl rsa -noout -modulus -in name_of_private_key_file.key | openssl md5 2. Rename both ssl certificate and private key to reflect its CN and validity year.              Example:     This certificate below has a CN = cp.example.com and validity year from 2023 to 2024.     #/> openssl x509 -in new_ssl_certificate.crt -noout -subject -issuer -dates            subject=C = MY, ST = Kuala Lumpur, L = Kuala Lumpur, O = Example Organization, CN = cp.example.com         issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1         notBefore=Jun  9 00:00:00 2023 GMT         notAfter=Jul  2 23:59:59 2024 GMT     Rename the ssl certificate file name and its private key pair file name as below or to something equal:          #/> mv new_ssl_certificate.crt cp_example_com_2023-2024.crt     #/> mv new_ssl_certificate_private_key.key cp_example_com_2023-2024.key     IF the ssl certificate is a wildcard certificate include the word 'wildcard' in the name of the file too.          Example of a wildcard ssl certificate. Notice that the CN has a wildcard character '*' infront of the domain name. This certificate is allowed to secure multiple sub domain of cp.example.com.         #/> openssl x509 -in new_ssl_certificate.crt -noout -subject -issuer -dates            subject=C = MY, ST = Kuala Lumpur, L = Kuala Lumpur, O = Example Organization, CN = *.cp.example.com         issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = Thawte TLS RSA CA G1         notBefore=Jun  9 00:00:00 2023 GMT         notAfter=Jul  2 23:59:59 2024 GMT Notes: This step can be skipped as there is an option to rename the file or provide description of the ssl certificate and its private key in the next step. 3. Upload both files to Provider Control Panel (PCP).     At PCP go to My Profile > Personal Data > User Repository > Upload Item > In field Item type drop down menu, pick Certificates >      (If step 2 was skipped at field Item name pick custom and name the file with a meaningful name) >      (OR If step 2 was skipped, provide meaningful description in the Item description field) >      At field Path click on Choose file > Choose the ssl certificate file > Click Submit.          Repeat the same step to upload the private key but at field Item type pick Private keys.     Once they are uploaded, both certificate and key are now available from the User repository and SSL Certificates. 4. Backup the current brand ssl certificate located in the UI nodes or brand-ui-cluster-ui pods:      Location: /etc/pki/tls/certs/ 5. Update brand with the certificates and private key from the User repository.          At PCP go to System > Settings > Brands > Search for the brand that requires the ssl certificate update > click on the brand name > click on tab Certificate > Install New Certificate >     Pick install from Repository > Next>> >      Pick the previously uploaded certificate > Next>> >      Pick the previously uploaded key > Finish.

Original Publishing Date:  2023-08-29 Starting with version 21.0, CloudBlue no longer supports Dummy Gate. This means, that subscriptions that were provisioned using this gate must be either canceled or migrated. This article explains how to migrate such subscriptions. Migration procedure consists of four main steps: Obtaining the migration script Exporting subscription information Preparing a mapping file for old and new resources Migrating subscriptions Limitations Information about only the subscriptions meeting these criteria will be exported: The subscription is not terminated. One of the following is true about the subscription: It is based on the service template that uses Dummy Gate for provisioning. At least one of the resources in subscription is provisioned through Dummy Gate. In case of a composite resource, one of the included resources is provisioned through Dummy Gate. The following subscriptions will not be migrated despite they will appear in the exported file: The subscription is not active and running. The subscription does not have an active subscription period. There is a not completed order for the subscription. The subscription includes composite resources. The subscription includes resources with consumption type “Usage”. The subscription is based on a non-dummy-gate service template, but it includes resources provisioned through Dummy Gate. The subscription is based on a Dummy Gate service template, but it includes resources provisioned through another, non-dummy gate. The following limitations apply to all migrated subscriptions: The information about parent subscription will be lost for the migrated subscription. If the migrated subscription does not have a resource, resource rates will be added for that subscription during the migration. Prerequisites CloudBlue Commerce version is 20.5. For each service template of the migrated subscriptions, a corresponding product line must be created using PLM. For each service plan of the migrated subscriptions, a corresponding plan must be created using PLM. Notes on Creating Product Lines and Plans in PLM General procedure on how to create product lines and plans can be found in the documentation: https://docs.cloudblue.com/cbc/20.5/premium/content/Product-Lifecycle-Management/introduction.htm. Below are notes and recommendations that should be considered when creating product lines and plans in PLM as a replacement for Dummy Gate service templates and plans respectively. Configuration of the new plans created in PLM must be identical to the plans they are replacing. The following settings must not have any differences: BillingPeriodType BillingPeriodDuration RecurringType PricePeriod SetupFeePerUnit RecurringFeePerUnit Depending on the partner and the level at which the prices are defined, plans created at provider or operational unit level can be delegated either through importing the PPR file or through adding them as delegated to the reseller service template.  When the prices are set, the plans should be delegated down to the distribution chain. Note: If there are resellers that could redefine plan prices at their level, it has to be decided if the prices can be synchronized throughout the distribution chain. To ensure smooth migration, the prices in the new plans must be the same as in the original plans. If the original plans were promoted by parent plan, the respective new plans should be added to the existing promotions. If the original plans or resources in those plans were discounted, the respective new plans and resources should be linked to the same discounts. To avoid creation of multiple fulfilment requests that will require manual actions, fulfillment type of the original plans must be set to Automatic, while for product lines created in PLM it must be Instant. Once the migration is finished, the fulfillment type can be changed back to the original value. Step 1. Obtain the Migration Script The script is launched from the CloudBlue Commerce management node. To obtain the script, complete these steps: Log in to the management node. Download this script package. After you downloaded the script package, use this command: # rpm -Uvh The script will be placed to /usr/local/pem/migrate_dummy_gate_subscriptions.py. Step 2: Export Subscription Information For the export purpose the downloaded script can be used with the following parameters: # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py [--csv-out FILE] [--type {s,p,t}] [ID [ID ...]] --csv-out. It is used to specify the file to which the information will be exported. --type. It indicates the export migration type. Possible values are: s – subscription, p – plan, t – service template. ID. It is required to pass the identifier of the subscription, service template or plan. It can be used as follows: To export information on all subscriptions that are associated with a Dummy Gate. Below is the usage example for such a case: # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-out /tmp/dg_subs.csv To export information on all subscriptions on the specified templates. # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-out /tmp/dg_subs.csv --type t 1000071 1000469 To export information on all subscriptions to the specified plans. # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-out /tmp/dg_subs.csv --type p 31 To export information on specific subscriptions. # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-out /tmp/dg_subs.csv --type s 1000001 1000079 1000911 As a result, a file with the specified name will be created with the information about the subscriptions that use a Dummy Gate. You can explore the file to learn if there are issues with some of the subscriptions. The Comment column includes the necessary information. Step 3: Preparing resource mapping file Based on the information obtained in the previous step, prepare the mapping.csv file with the information to which new resources the old resources must be migrated. Use the mapping_sample.csv file as an example. The exported file from step 2 contains information about Dummy Gate subscriptions that should be used for preparation of new product lines and service plans. It can also be used as a base for mapping which is required to complete the migration. Please note that the first column is SubscriptionID that indicates to which subscription the source and target plan information is related. To create a mapping file, you need to specify target plan details for each existing Dummy Gate subscription. In the mapping file, for the columns: SourcePlanID SourcePlanName SourceSubscriptionPeriodID SourceTemplateID SourceResourceID_1  SourceResourceID_2 you need to specify information about new, target service plans in these columns: TargetPlanID TargetPlanName TargetSubscriptionPeriodID TargetTemplateID TargetResourceID_1 TargetResourceID_2 Note: The number of resource ID columns must be the same as the number of resource in the service template. In the next steps, this mapping will be used during the migration process and any unnecessary information from the file will be ignored by the script. The mapping file must contain information only about those subscriptions that you need to migrate. Subscriptions that should not be migrated or do not have a target plan configured must not be mentioned in this file. Plans and plan periods mentioned in the mapping file must exist on the same distribution chain level as the corresponding target plans and plan periods. Step 4: Migrate Subscriptions During migration, for each migrated subscription, the script will do the following: Create a subscription in OSS. Configure upgrade path from the source to the target plan. Map Dummy Gate resource onto PLM in-house resource for correct resource limit migration. Place a change order to switch the subscription to the target plan. Before you start the migration, make sure the FEA_NoRefundDuringPlanSwitch BSS feature is turned off. You can use the following parameters when running the migration: --type. Use this parameter to narrow the migration scope. Even if the exported file lists more subscriptions for migration, only those you specify in this parameter will be migrated. Possible values are: s – subscription, p – plan, t – service template. If omitted, all eligible subscriptions from the input file will be migrated. The script can be run in several ways: To migrate all eligible subscriptions listed in the CSV file, run this command: # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-in To migrate a single subscription from the ones listed in the CSV file, run this command: # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-in --type s To split subscription migration by the service template they are based on and run the migration for each subscription group separately, follow this example: # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-in mapping.csv --log 1000073.log --type t 1000073 # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-in mapping.csv --log 1000074.log --type t 1000074 Note: You must wait for the previous migration script execution for one group before running it for another group. To group subscription migration by their service plan, and run the migration for each subscription group separately, follow this example: # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-in mapping.csv --log 101.log --type p 101 # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-in mapping.csv --log 102.log --type p 102 # python /usr/local/pem/migrate_dummy_gate_subscriptions/migrate_dummy_gate_subscriptions.py --csv-in mapping.csv --log 103.log --type p 103 Note: You must wait for the previous migration script execution for one group before running it for another group. If an order cannot be completed right away, the script will ask you to choose one of the options: Abort script execution. Skip the order and proceed to the next subscription. Wait 3 minutes for order completion. You can use this time to take manual steps if required, or to verify the order status. Known issues and limitations In some cases, change orders can be generated within the migration and, as a result, the customers will be charged for the period from the migration date to the subscription period end. As a result, such change orders will not have a zero total, while the total of a correct change order created during migration must be zero. Change orders placed during migration can only be canceled before provisioning starts.

Question Customer want to disable the option "login as" for users under certain role so these users can not login as other users, customers or resellers. Answer Impersonation in PCP/RCP/UX1 for Provider/UX1 for Resellers depends on the following privileges: Own Customer's CP Access Customer's CP Access Own Reseller's CP Access Resellers CP Access   Go to Operations > System > Settings > Security > Select role you want to modify > Privileges  > Edit > Disable the required or all privileges from the above list and save changes. Note: Disable these privileges will not remove button "login as", but clicking it will redirect you to the login page with error message.

Question It is required to disallow users under certain role to edit or create other users. Answer It is possible to remove the "edit" or "create" button from the privileges list. This button depends on the following OA privileges: Own Users Reseller Users All Users Go to Operations > System > Settings > Security > Select role you want to modify > Privileges  > Edit > Disable the required or all privileges from the above list and save changes.

Symptoms Customer has placed a Cancellation Order (CL) for a PLM subscription, but this CL is failed or rejected on Connect and manually cancelled on CBC. However, this subscription keeps in "disabled" status on the OA side even if it is back to "active" on BA. Cause CF order failed on stopping of the subscription. In this case if stopping of the subscription fails then the subscription is not stopped. And on the cancellation of CF order it will not be started due to it has not been stopped on CF order placement due to error. The pem.revertToSubscriptionStateSnapshot() openapi method is not called on the cancellation of the CF order.  This issue is caused by software issue #OA-38609. Resolution There is an available w/a. In case of failed tasks stuck on the task manager queue after CL cancelled, also need to cancel. Once subscription queue is clean on task manager, enable subscription manually with pem.enableSubscription method: https://docs.cloudblue.com/cbc/20.4/premium/content/Operations-Public-API-Reference/pem.enableSubscription.htm

Symptoms Google Workspace order fails with:  "Message from the Vendor: GOOG_010: An error occurred when creating the customer. Google returned the following error: Requested domain is blocked: xxxxxxxxxx" Product details: Product: PRD-550-104-278 Vendor: VA-188-593 Cause Google does not allow purchasing services with the mentioned domain name due to some reason (security, fraud, copyright, etc.). Example: a domain name for Google Workspace cannot contain "google" string in it. Resolution Try using a different domain name.

Symptoms Level 1 reseller who has an in-house products plan purchased under their account tries to upload new PPR file and gets an error: { "error": "com.ingrammicro.imcp.library.aps.exception.APSError", "packageId": "d07c417e-9a8d-471e-bd98-5201f804e621", "message": "Validation 'Sales categories without plans' failed with an unexpected error. Check logs.", "http_request": "POST https://inhouse-products:8081/rest/application/23c7dca5-158e-4727-b792-07c47d341a8f/parseConfig" } SalesCategoryDetailedListGet_API will fail with access denied exception: 24-01-05 10:22:14.668 billing RQ5100438 TH00057 TRC] [xmlrpc_57_Execute_1704450134.666733] TRACE START SalesCategoryDetailedListGet_API [24-01-05 10:22:14.668 BM_Object RQ5100438 TH00057 NTE] Entering method BM.SalesCategoryDetailedListGet_API(user = 1, SID = 0, lang = en, request = 5100438, localObject = 0, transaction = 7376269 (HP)) [24-01-05 10:22:14.668 BM_Object RQ5100438 TH00057 NTE] 2 input arguments [int32_t: 1002412, int32_t: Int32(NULL)] [24-01-05 10:22:14.668 BM_Object RQ5100438 TH00057 TRC] +++[0] ListResult* BM::SalesCategoryDetailedListGet_API(Int, Int)(1002412) [24-01-05 10:22:14.671 BM_Object RQ5100438 TH00057 TRC] ...[0] *** INTERRUPTED BY EXCEPTION *** ListResult* BM::SalesCategoryDetailedListGet_API(I nt, Int) [24-01-05 10:22:14.671 BM_Object RQ5100438 TH00057 NTE] Finished method BM.SalesCategoryDetailedListGet_API(user = 1, SID = 0, lang = en, request = 5100438, localObject = 0, transaction = 7376269 (HP)) [24-01-05 10:22:14.671 BM_Object RQ5100438 TH00057 NTE] ExceptionResult: Access Denied. SalesCategoryDetailedListGet_API call made during PPR upload accepts accountId as an argument. Current implementation passes memberId instead of accountId. If there is no accountId equal to the memberId passed as the argument, the call fails with AccessDenied exception. The issue has been identified in PLM version: inhouse-products 2.0-1019 Cause The case has been analyzed further and submitted to CloudBlue Automation R&D Team as an internal issue with ID PDI-2773. Resolution Upgrade to PLM version 2.2 or higher. There is no w/a for older versions for PLM.

Symptoms A customer purchases a 1 Year(s) subscription. A year later the subscription was about to expire when it was renewed, according to the subscription's autorenewal configuration, for 1 Month(s). As expected, in Commerce, the subscription period changed to 1 Month. The issue is that when the subscription was renewed in MSFT it was renewed for 1 Year(s) not for a month, leading to a misalignment with CBC. In the oss logs it can be seen that oss received openapi call to renew subscription: 2023-11-12T02:01:17.106869649Z 12-11-2023;03:01:17,106 INFO [openapi:159138 openapi:159138 remoting-task-2168 oss] c.p.p.s.x.c.OpenApiMethodReference handling method: renewSubscription invocation of service: core-ear/provisioning-ejb/SubscriptionManagerOpenAPI!com.parallels.pa.service.provisioning.ejb.SubscriptionManagerOpenAPI params: {current_period=1, subscription_id=, txn_id=, shutdown_date=0, terminate_date=0, current_period_type=Year(s), new_period_type=Month(s), expiration_date=, new_period=1, order_id=, start_date=} 2023-11-12T02:01:17.11934183Z 12-11-2023;03:01:17,119 DEBUG [openapi:159138 openapi:159138 remoting-task-2168 oss] c.p.p.s.p.e.SubscriptionManagerOpenAPI renewSubscription eventJson: {"orderId":,"newPeriod":{"period":1,"periodType":"Month(s)"},"currentPeriod":{"period":1,"periodType":"Year(s)"},"startDate":"","expirationDate":""} There is also an event in PLM from oss with parameters={orderId=, newPeriod={period=1, periodType=Month(s)}, currentPeriod={period=1, periodType=Year(s)}, startDate=, expirationDate=}}:  Cause The issue is caused by an Invalid configuration in PPR. Subscription auto-renew to a different period scenario is not supported for the switch to the same plan. By default, all renewal operations for connect products will be processed instantly by PLM without sending any request to the Connect system. Resolution Autorenew switch to a period and a different plan was implemented in the scope of PFR-3132 (change order is created in that case). To align the subscription between platforms, it will have to be terminated in offline mode and re-imported.

Symptoms Customer with UX1 MP version higher than UX1MP-6.4.1142 where the function to remove all was introduced tries to remove all items from the cart after adding one more products and click the Clear cart link in 'UX1 Marketplace > Cart > Clear Cart'. But the 'REMOVE ALL' button is not shown: Cause The reason is the changes in a skin css. The used custom skin has an instruction display: none !important to hide all .btn-danger elements. So the 'Remove all' button having such class is hidden as well. There is no ability to check who the editor of the custom skin was. Resolution Customer need to remove this instruction, or introduce a more customized selector.

Platform was upgraded to V21. Where is Encryption Keys? Why cant we use them? Answer -  Encryption keys in Billing were used only to work with real credit cards (not with tokens but with full credit card credentials that were stored directly in BSS DB). In order to do this in compliance with PCI-DSS - Encryption keys were used, in order to store credit card number (and other parameters) in the DB in the encrypted form, and later decrypt when payment needed to be created. Starting from V21 - all Payment Plugins that worked with real credit cards were decommissioned, they are no longer available, so the need of Encryption Keys is also no longer there The documentation https://docs.cloudblue.com/cbc/21.0/PCI-DSS-Compliance-Guide/Generating-Encryption-Keys.htm for V21.x is a doc bug. Credit Card plugins are not really required when we have PHP payment plugins that support tokens - in this case the customer does not provide credit card number to BSS - it provides it to the payment processor (stripe for example) and then Stripe just returns back to BSS "Token" - it does not need to be encrypted and therefore we're by default PCI-DSS compliant.  In short - BSS and Stripe communicate in "Token" format which automatically make platform in v21 a PCI-DSS compliant.