Original Publishing Date: 2022-04-13 Symptoms Ploop container consumes significantly more disk space on the server, than the data size inside it: [root@vz ~]# du -h /vz/private/101/root.hdd/root.hds 154G /vz/private/101/root.hdd/root.hds [root@vz ~]# vzctl enter 101 entered into Container 101 CT-101-bash-4.1# df -h Filesystem Size Used Avail Use% Mounted on /dev/ploop18346p1 197G 62G 133G 32% / none 1.0G 4.0K 1.0G 1% /dev Cause Depending on the data structure inside a container, a scheduled daily job that compacts ploop images automatically, /etc/cron.d/pcompact, might not be effective. One of the possible reasons of such behavior is high fragmentation level inside a container. Resolution Optimizations of pcompact are planned in future Virtuozzo updates in scope of request with internal ID #PSBM-30164. For now, there are few methods to compact a container manually. Truncate unused blocks with the help of prl_disk_tool utility: [root@vz ~]# prl_disk_tool compact --hdd /vz/private/101/root.hdd/ Downsize stopped container and upsize it back to the original value: [root@vz ~]# vzctl stop 101 [root@vz ~]# prl_disk_tool resize --hdd /vz/private/101/root.hdd --size 75000M [root@vz ~]# prl_disk_tool resize --hdd /vz/private/101/root.hdd --size 199000M Internal content Another undocumented solution: [root@vz ~]# vzctl stop 101 [root@vz ~]# vzctl set 101 --diskspace 200G --save --offline NOTE: At least the same amount of space consumed by the container should be free on the node to perform offline resize operation.

Original Publishing Date: 2022-04-13 Urchin service is not supported beginning from Odin Automation Premium 7.0 and it will be removed during the upgrade In order to prepare for upgrade to Odin Automation Premium 7.0, one needs to perform the following steps: Unprovide all 'Urchin' resources using any appropriate way: set the resource limit to zero in all subscriptions directly, change the corresponding Service Plans in Business Automation and apply these changes to Operations Automation or by migrating to other plans without the resource. Remove 'Urchin' resources from Service Plans in Business Automation and apply these changes to all subscriptions according to guide Synchronizing Subscriptions From Plan. Select only Remove obsolete resource(s) check box during subscription synchronization. Wait until Urchin unprovisioning tasks are processed (Operations > Tasks). Cancel Urchin-related periodic tasks in (Operations > Tasks > Scheduled Tasks). Remove all Urchin-related Resource Types from all Service Templates and then remove these Resource Types from the system. Remove the following packages from host(s): urchin (service) urchin7 (service) Internal content

Original Publishing Date: 2021-11-01 Before the upgrade of an order flow, the pre-check script is run automatically. This pre-check script checks existing order flows for a possible upgrade. The following checks are performed: Whether identifiers of new order flow handlers already exist and contain different methods. In this case, the pre-check script writes this inconsistency into a log file. Whether “AP” status already exists for “SO”, “CH”, “RN”, and “CF” orders. Refer to: https://cbportal.freshservice.com/support/solutions/articles/23000100185 https://cbportal.freshservice.com/support/solutions/articles/23000100203 https://cbportal.freshservice.com/support/solutions/articles/23000100218 https://cbportal.freshservice.com/support/solutions/articles/23000100222 Whether “VC” or “VF” statuses already exist and have incorrect handlers for “SO”, “CH”, “RN”, and “CF” orders. In this case, the pre-check script writes this inconsistency into a log file. If the precheck script fails, perform the following actions: Ensure that the following identifier exists in the “FlowHandler” table: 158. If it does not exist, add this identifier or replace the incorrect identifier with the correct one using the move_old_handlers.py script. To use this script, copy it to the BSS node and run. Fix inconsistencies found by precheck in custom order flows using the default order flow as an example. If the order flow already has “VC” or “VF” statuses, rename them using the interactive rename-status.py script. Note that this script does not change the default record in the “OrderOperation” table. If you want to rename the initial status of an order flow, this record must be updated manually and with care. Make sure that the actions from these articles are applied and the flow is configured in accordance with these articles: https://cbportal.freshservice.com/support/solutions/articles/23000100222 https://cbportal.freshservice.com/support/solutions/articles/23000100185 https://cbportal.freshservice.com/support/solutions/articles/23000100203 https://cbportal.freshservice.com/support/solutions/articles/23000100218 If the described steps did not work, configure the order flow after the upgrade: Insert the new "VC" status before the "AP" status for “SO”, “CH”, “RN”, and “CF” orders: VC -> AP (success), VC → VF (fail). The new status must have the following handler: VC: 'OF_ValidateActivationDate' To add new statuses and their transitions, complete these steps: Log in to the PCP, go to Billing > Settings > Order Processing > All Order Flows, and click the required order flow and then the required order type. In the Order Statuses tab,  add new statuses. Flags for them can be taken from the status before which new statuses are added, or from the same statuses from the default order flow. In the Order Flow Transitions tab, add their transitions. The new statuses must have the following transitions (you can copy them from the default order flow): For “SO” orders: From: "SP"; Success: "VC"; Fail: "SP"; Action: "Obtain Subscription Parameters"; Order Flow Handler: "OF_RetrieveSubscriptionParametersExc"; Transition Type: "On Event" From: "VC"; Success: "AP"; Fail: "VF"; Action: "Validate Activation Date"; Order Flow Handler: "OF_ValidateActivationDate"; Transition Type: "On Event" From: "VF"; Success: "SP"; Fail: "VF"; Action: "Resubmit Activation Date Validation"; Order Flow Handler: "None"; Transition Type: "Manual" Status AP must already exist. Refer to the following articles for details: https://cbportal.freshservice.com/support/solutions/articles/23000100222 https://cbportal.freshservice.com/support/solutions/articles/23000100185 https://cbportal.freshservice.com/support/solutions/articles/23000100203 https://cbportal.freshservice.com/support/solutions/articles/23000100218 If you have any customized transitions, you must update them too. If an order flow still cannot be modified, send its copy to the support team for investigation. Run the upgrade script.

Original Publishing Date: 2021-11-08 Before a provisioning order type is added to the system and order flow that uses this new order type is created, the pre-check script is run automatically. This pre-check script performs necessary checks. The following checks are performed: Whether identifiers of specific order flow handlers already exist and contain specific methods. In this case, the pre-check script writes this inconsistency into a log file. Whether user-defined enumerators "ORDER_PR" already exist for any accounts. If the precheck script fails, perform the following actions: Ensure that the following identifiers exist in the “FlowHandler” table: 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 100, 25. If they do not exist, add these identifiers or replace the incorrect identifiers with the correct ones using the move_old_handlers.py script. To use this script, copy it to the BSS node and run. Rename enumerators "ORDER_PR" in PCP or RCP UI: Log in to the control panel as a provider or reseller. Go to Billing > System > Settings > More Finance Settings > Enumerator Classes. Create a copy of the existing "ORDER_PR" enumerator with configured order types and documents types. Remove the original "ORDER_PR" enumerator. Run the upgrade script.

Original Publishing Date: 2022-02-15 Before switching order flows to work with provisioning orders, the pre-check script is run automatically. This pre-check script checks existing order flows for a possible upgrade. The following checks are performed: Whether identifiers of specific order flow handlers already exist and contain different methods. In this case, the pre-check script writes this inconsistency into a log file. Whether “AN” and “AS” statuses already exist and have incorrect handlers for “CH” order. In this case, the pre-check script writes this inconsistency into a log file. Whether “NC” and “CO” statuses already exist and have incorrect handlers for “CH”, “SO”, “CF”, and “RN” orders. In this case, the pre-check script writes this inconsistency into a log file. Whether “EC”, “AD”, “I9”, “I4”, “MO”, “MN”, “LO”, “PF”, “PR”, “PN”, “AP”, “NF”, “VC”, “VF”, “PD” statuses do not exist or have incorrect handlers for “CH”, “SO”, “CF” and “RN” orders.  Whether “AU” status does not exist or has incorrect handlers for “SO” orders. In this case, the pre-check script writes this inconsistency into a log file. Whether some unsupported features are active (“FEA_PostApproval” or “DelayedLandingUsageBilling”). In this case, the pre-check script writes this inconsistency into a log file. Whether unsupported order item type “One-time Fee” or service gates (KAGATE) are used. In this case, the pre-check script writes this inconsistency into a log file. If the precheck script fails, perform the following actions: Ensure that the following identifiers exist in the “FlowHandler” table: 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 25. If they do not exist, add these identifiers or replace the incorrect identifiers with the correct ones using the move_old_handlers.py script. To use this script, copy it to the BSS node and run. Fix inconsistencies found by precheck in custom order flows using the default order flow as an example. If the order flow already includes new statuses, rename them using the interactive rename-status.pyscript. Note that this script does not change the default record in the “OrderOperation” table. If you want to rename the initial status of an order flow, this record must be updated manually and with care. If the “AP” or “AU” statuses do not exist, make sure that the actions from https://cbportal.freshservice.com/support/solutions/articles/23000100185 are performed and the order flow was configured in accordance with this article. If the “VC” or “VF” statuses do not exist, make sure that actions from https://cbportal.freshservice.com/support/solutions/articles/23000100483 are performed and the order flow was configured in accordance with this article. If the “AS” status does not exist, make sure that actions from https://cbportal.freshservice.com/support/solutions/articles/23000086235 are performed and the order flow was configured in accordance with this article. Deactivate unsupported features “FEA_PostApproval” and “DelayedLandingUsageBilling”. Run the upgrade script.

Original Publishing Date: 2022-04-28 Questions How do I know if a product works via Connect Adapter or via PLM? Can I use both at the same time?  Can one affect another? Answer A product can be configured to work in CBC both ways simultaneously. Details below. Note: The two configurations do not affect each other, i.e. they work independently. So if you choose to do everything via PLM, you do not have to fix anything related to Connect Adapter configuration. Via PLM (recommended way): Visible in PLM menu UX1 PCP > Import from Connect: PLM service template for that product will have product ID in its name, see picture at the bottom. Via Connect Adapter (old technology): Visible in UX1 PCP > Connect If you click on Manage, you will find it's service template ID: Also visible in PCP > Connect Here you can see both STs in Classic PCP: #147 - Connect Adapter #161 - PLM

Original Publishing Date: 2022-05-04 Symptoms On attempt to place a new Sales Order with "Create a new Microsoft account" or "Use an existing Microsoft account", the page is not moving to the next screen without any error. Error message is visible in the Browser Console: Please choose the special qualification that the customer is eligible for Cause Microsoft365 NCE application is not upgraded from the PLM side  Resolution Upgrade Microsoft365 NCE application from the UX1 Provider Control Panel > Import from Connect > Product ID.

Original Publishing Date: 2022-05-06 Symptoms Sales Order is failed with an error from CB Commerce side: Fulfillment Request PR-8604-6136-****-*** created. State set to Failed. Reason: There has been an error on checkout the cart: For the current term, the requested number of 1 asset(s) exceeded the remaining limit of -1 assets allowed per customer. and PR-request is failed from the CB Connect side with an error in Microsoft365 connector log: PR-8000-6000-****-*** MICROSOFT_AAD_API_Response "POST" : "https://api.partnercenter.microsoft.com/v1/customers/ff46qefu-845b-4efc-b9ea-*****/carts/c1c07c9c-aefe-42fc-b16t-8a1a95f06f39/checkout", MS-CorrelationId:"3a8a50d0-c7eb-11ec-89e6-******", MS-RequestId:"3a8a50d0-c7eb-11ec-******" : {'orderErrors': [{'orderGroupId': '0', 'code': 800089, 'description': 'For the current term, the requested number of 1 asset(s) exceeded the remaining limit of -1 assets allowed per customer.', 'attributes': {'objectType': 'OrderError'}}], 'additionalInformation': [], 'attributes': {'objectType': 'CartCheckoutResult'}} Cause An issue from Microsoft side. Resolution Please contact Microsoft Technical Support and provide them MS-RequestId to investigate the issue further. 

Original Publishing Date: 2022-05-19 Symptoms In an attempt to import PPR file for Inhouse Product, an error occurs: "Unexpected error while parsing configuration" with an error in in inhouse-products pod 19-05-2022;08:38:30,638 WFLYEJB0034: Jakarta Enterprise Beans Invocation failed on component ExcelConfigManagementBean for method public abstract com.odin.platform.excel.rest.ConfigurationInfo com.od in.platform.excel.api.ExcelConfigManagement.parseExcelConfig(byte[],int): javax.ejb.EJBException: Unexpected error while parsing configuration, please contact support         at deployment.inhouse-products-backend.war//com.odin.platform.excel.ejb.excelwizard.ExcelConfigParser.parse(ExcelConfigParser.java:56) at deployment.inhouse-products-backend.war//com.odin.platform.excel.ejb.ExcelConfigManagementBean.parseExcelConfig(ExcelConfigManagementBean.java:174) Cause PPR file has the incorrect column name "#N/A" from the "ServicePlan" sheet. Resolution Make sure that the PPR file is correct and matches with the official documentation https://docs.cloudblue.com/cbc/21.0/Product-Lifecycle-Management/File-Requirements.htm 

Original Publishing Date: 2022-05-19 In CloudBlue Commerce version 21.7, the Bill for Subscriptions that are on hold functionality of Credit Terms has been discontinued. If this new BSS behavior does not suit your business needs, you can temporarily return the previous behavior by enabling the following special feature in the database: FEA_USE_BILL_SUBSCRIPTION_ON_HOLD. Use these instructions. After enabling it, the respective checkbox becomes available for Credit Terms. This setting allows the provider to collect payments as follows: When this setting is enabled, the system issues invoices on billing dates to all customers and resellers for all their subscriptions including those that are currently on hold. If a reseller’s subscription is on hold, the system will still bill the reseller for all of the reseller’s customers. This means that the provider can receive regular payments from all accounts and for all subscriptions, including those which are suspended. When this setting is disabled, the system does not issue invoices on billing dates for subscriptions that are on hold until they are removed from hold (after that, a consolidated invoice will be issued). This means that the provider will not receive regular payments from such accounts or for such subscriptions until they are removed from hold. This setting applies to all customers or resellers that belong to the customer class to which these credit terms are assigned. This setting does not modify the charge calculation logic. Important: Before enabling this functionality, you must contact your TAM, Product management, or Suport team as this workaround is temporary.