Release Your Workspace

Release your workspace so you can get your draft from the Configurator Models work area into a production environment, such as Oracle Order Management.

Try it.

1. Go to the Configurator Models work area, then open your workspace.

2. Simulate your release to make sure the workspace doesn't have any errors.

   We recommend that you simulate the release before you actually do the release. Here's how:

   • On the Workspace page, click Release > Generate Prerelease Report.

     The report simulates the release without actually releasing the workspace. You can create a report at any time to test your workspace, even if you aren't planning to release right away.

   • In the dialog that displays, note the process ID's value, such as 493400.

   • Go to the Scheduled Processes work area, then monitor the status of the process until it says Succeeded.

     Attribute	ParameterValueCode
     Name	Workspace Prerelease Report
     Process ID	493400
     Status	Succeeded

   • In the search results, click the row that has your process.

   • In the Log and Output area, click the link next to Attachment, then examine the log file.

   • If the process never gets to Succeeded or if it fails, then examine your setup.

     • Make sure the end date for each participant, transactional attribute in the item's class, or value in a value set happens before the workspace's end date.

     • Verify the status of all configurator rules that the workspace uses for the model.

3. Go to the Configurator Models work area, open your workspace, then notice the values.

   Attribute	Value
   Prerelease Report Process ID	493400 It's the ID of the most recent report that you created.
   Status	Contains one of: Generating Prerelease Report. The scheduled process is currently running and creating the report. In Development. The scheduled process is done running.

4. If all looks good, click Release.

What Happens When I Release?

Here's what Configurator does when you release your workspace.

• Updates the workspace status from In Development to Released.

• Puts any modifications that you have made to participants into production according to the workspace's effective start date.

• Changes each model that's a participant from a draft to a new version, and sets a new version number for the model.

  Note that you can no longer edit drafts of these participants in this workspace, but you can test a released model in a released workspace.

• Removes all draft participants that you haven't modified from the workspace.

• Writes an impact analysis to the log for the scheduled process that does the release. If there's a problem, you can view suggestions in the log for how to fix it.

Configurator also recompiles each rule that the release affects, including rules in models that aren't in the released workspace. If you make a change in a workspace and release it, and if the change causes a rule to become invalid, then the result depends on whether the model that you release is already in production or is still a draft:

• In production. Configurator prevents the release. You must add the model to the workspace and fix the rules.

• A draft. Configurator does the release, and adds an entry in the log of the Release Workspace scheduled process that identifies the rule that you need to fix.

Note

• You can't modify a workspace's effective start date after you release it, so make sure you release your changes immediately before you need them in production.

• The release includes all participants that exist in the workspace. You can't release only some of the participants in a workspace.

• You can't modify a participant after you release a workspace.

Manage Releases Across Workspaces

Consider an example where you have three workspaces, all of them have the same zCZ_CAR4DRSDN model as a participant, and the model is in draft status in all workspaces.

What the Numbers Mean

Number	You Set The Effective Start Date in Workspace A To	You Release it On	Configurator Puts the Model Into Production On
1	6/1/22	5/15/22	6/1/22
2	7/1/22	6/15/22	7/1/22
3	8/1/22	6/15/22	8/1/22

Note

• Notice how versions of the model move from draft to production after you release the workspace.

• You can release a workspace before its effective start date, but the model doesn't go into production until after the effective start date.

• You can release different workspaces that contain the same model on the same date as long as the effective start dates of these workspaces aren't the same. If you do this, then you must release the workspace that has the effective start date that happens first, and then release the workspace that has the effective start date that happens later.

Releasing an updated model might affect other models that also have the model but that aren't part of the workspace that you release. Assume you release workspace A. If you haven't released workspace B, and if the model's effective start date in workspace B happens after the model's effective start date in workspace A, then Configurator will apply whatever changes that you made to the model in A to the model in B.

Don't Release Your Workspace Until It's Ready

You can set your workspace's effective start date to any date in the future, but we recommend that you release it into production as close to the effective start date as possible. You can't release changes to workspace participants and you can't release future changes until after the effective start date happens.

Assume today is January 1, you release your workspace, and the effective start for the workspace is February 1. This means you released changes that don't go into effect until February 1, and you can't reverse these changes until after February 1. You're stuck with them for a whole month, even though you might need to change them in the interim. To help avoid this problem, Configurator comes predefined to prevent you from releasing a workspace more than 1 day before its effective start date.

But you can modify this behavior to meet your needs. In this example, you set up a parameter to tell Configurator not to release your workspaces until 2 days before the effective start date.

1. Make sure you have the privileges that you need to administer Order Management.

2. Go to the Setup and Maintenance work area, then select the Order Management offering.

3. Search for the Manage Pricing Parameters task, but don't open it.

4. Download your setup data.

   • In the search results, in the row that has Manage Pricing Parameters in the Task column, click the icon in the Actions column, then click Export to CSV File > Create New.

   • On the Export Setup Data to CSV File page, click Submit.

   • On the Setup page, in the search results, in the row that has Manage Pricing Parameters in the Task column, click the icon in the Actions column, then click Actions > Export to CSV File > View All.

   • On the Export Setup Data to CSV File History page, look at the date to determine the row that has your export, make sure the Status for that row is Completed Successfully, then click Actions > Download > CSV File Package on that row.

   • In the dialog that displays, save the file to your computer.

     This file contains the setup parameters. For this example, assume the file name is Manage Pricing Parameters_20210909_093224_303.zip.

   • On the Export Setup Data to CSV File History page, click Done.

5. Modify the parameter.

   • Use a compression utility, such as WinZip, to extract the file that you downloaded.

   • Open the ORA_QP_PRICING_PARAMETER_VALUE.csv file.

   • Delete all the rows in the file except for the row that has QP_WS_RELEASE_THRESHOLD in the ORA_QP_PRICING_PARAMETER.ParameterCode column.

   • Set the value.

     ORA_QP_PRICING_PARAMETER.ParameterCode	ParameterValueCode
     QP_WS_RELEASE_THRESHOLD	2 The default value for the parameter is 1, which means 1 day. You can set it to any decimal value that's greater than zero.

   • Save the ORA_QP_PRICING_PARAMETER_VALUE.csv file, then add it to the zip file that you downloaded, replacing the original ORA_QP_PRICING_PARAMETER_VALUE.csv file.

6. Upload the file.

   • Go back to the Setup page in the Setup and Maintenance work area.

     In the search results, in the row that has Manage Pricing Parameters in the Task column, click the icon in the Actions column, then click Import from CSV File > Create New.

   • On the Import Setup Data from CSV File page, click Browse, select Manage Pricing Parameters_20210909_093224_303.zip, then click Submit.

   • In the search results, in the row that has Manage Pricing Parameters in the Task column, click the icon in the Actions column, then click Import from CSV File > View All.

   • On the Import Setup Data from CSV File History page, make sure the Status attribute contains Completed Successfully. If it doesn't, wait a few minutes, then click Refresh until it does.

7. Test your work.

   • Open a workspace that has an effective start date that happens more than two days after today.

   • Click Release.

   • Verify that Configurator doesn't allow you to release the workspace but instead displays a message, similar to:

     You can't release the workspace because its effective start date happens after the latest allowed release date of 01/1/2022 12:00:00 PM.

For details, see Updating the Workspace Release Threshold for Oracle Configurator Cloud (Doc ID 2471288.1) on My Oracle Support.

Specify What Versions to Update

If you have a snapshot that participates in a rule in different versions of a model, then you can use the ORA_QP_RULE_RECOMP_DAYS_PAST parameter to specify which earlier versions of those rules you want to use when you release changes to the snapshot.

ORA_QP_RULE_RECOMP_DAYS_PAST specifies the number of days to look into the past, starting from when you release the snapshot.

Some of the changes that you make to a snapshot are always in effect and might prevent rules in earlier versions from working correctly. If the rules don't work correctly, then you might not be able to release the modified snapshot.

Changing a component's minimum or maximum value or deleting an item are examples of a change that Configurator assumes is always in effect.

Configurator can update rules in your model's earlier versions when you release the modified snapshot that participates in those rules.

If you make a change in your snapshot, and if that change affects your model's behavior in an earlier version, then updating the earlier version will help to make sure your model behaves as you expect it to across versions.

Guidelines

• To specify ORA_QP_RULE_RECOMP_DAYS_PAST, do the same procedure that you do in the Don't Release Your Workspace Until Its Ready subtopic, except modify the ORA_QP_RULE_RECOMP_DAYS_PAST parameter.
• ORA_QP_RULE_RECOMP_DAYS_PAST specifies the number of days in the past to update earlier versions up until your snapshot's release date.
• Specify the number of days before today. If releasing the snapshot affects the rule's version, and if that version is older than the value that you specify in ORA_QP_RULE_RECOMP_DAYS_PAST, then Configurator won't update that version.
• ORA_QP_RULE_RECOMP_DAYS_PAST comes predefined with a default value of 10,000, which means that Configurator will update all prior versions when you release your snapshot.
• If you don't need to validate any sales orders that are older than the current date, then set ORA_QP_RULE_RECOMP_DAYS_PAST to 0. Configurator won't update rules in prior versions when you release your snapshot.
• If you attempt to release a snapshot but it fails with an indication that a rule in an earlier version is failing, and if you don't need to validate runtime configurations on sales orders that you already submitted, then we recommend you set ORA_QP_RULE_RECOMP_DAYS_PAST to 0. Configurator will ignore all earlier versions.
• Configurator updates your rules when you release the snapshot.

Consider the Configuration Effective Date Parameter

If the value of the Configuration Effective Date parameter is:

• Current Date. We recommend that you set ORA_QP_RULE_RECOMP_DAYS_PAST to 0. Configurator will ignore all of your model's earlier versions, it will only update versions that are in effect on the current date or in the future.
• Any value that isn't Current Date. You must consider how far back into history you want the snapshot changes to affect your rule's behavior. We recommend that you use the default value of 10,000 days for ORA_QP_RULE_RECOMP_DAYS_PAST, or set it to 0.

For details about Configuration Effective Date, see Manage Your Validations.

Remove a Model from Production

You can remove a model from production. See Remove Your Model From Production.