Publishing Split-Model Policies to Exchange

During the custom split-model policy development cycle, you can upload the definition and implementation of your policy to Exchange to create a new Exchange assets to manage the asset versions and to distribute it to other users. For more information about Exchange, see Anypoint Exchange Overview.

For custom policies running in Local Mode, it is not required to publish your policy to Exchange. However, Exchange is a useful version control tool. It is your responsibility to distribute custom policies for Local Mode use.

When uploading your policy to Exchange, you can choose to either:

Publish a Custom Policy
Publish a policy if the policy version is still in development. This enables you to test and edit the policy version.

To learn about development assets, see Publish a Custom Policy.
Release a Custom Policy
Release the policy to create a definitive version of the policy. After releasing the policy, you must create a new policy version to edit the policy.

To learn about production assets, see Release a Custom Policy.

Every time you publish or release a definition and implementation asset, you create a new stable version of that asset in Exchange. For more information about stable state assets, see Stable State Assets.

After you upload your definition and implementation assets to Exchange, see Applying Custom Policies.

Before You Begin

Ensure that the Connected App you used to authenticate to the Anypoint Platform CLI has the Exchange Contributor scope applied.
Compile your Policy.

Publish a New Split-Model Policy

Create a definition project:
1. Make changes on the gcl.yaml
2. Execute make publish in the definition project to publish the development definition asset to Exchange.
Create an implementation project:
1. Update the definition_asset_id version field in the cargo.toml file to 1.0.0-DEV.
2. Execute make build-asset-files in the implementation project.
3. Code your policy logic and test locally.
4. Execute make publish to release the development implementation asset to Exchange for testing in lower environments.
5. Validate the policy works as expected. Complete steps C and D until testing is complete.
After validating the policy works as expected, release the both assets to Exchange:
1. In the definition project, execute make release to release the definition asset to Exchange.
2. In the implementation project, update the definition_asset_id version field in the cargo.toml file to 1.0.0.
3. Execute make release to release the implementation asset to Exchange.

Publish a Patch Version Update (Implementation Update)

After you have Published a new split-model policy, you can update the implementation asset for bug fixes or performance updates:

Develop the new policy implementation:
1. In the implementation project, update the patch number of version in the cargo.toml file. For example: 1.0.1.
2. Add the -DEV suffix to the definition_asset_id version field in the cargo.toml. For example: 1.0.0-DEV.
3. Execute make build-asset-files in the implementation project.
4. Code your policy logic and test locally.
5. Execute make publish to release the development implementation asset to Exchange for testing in lower environments.
6. Validate the policy works as expected. Complete steps D and E until testing is complete.
After validating the policy works as expected, release the implementation asset to Exchange:
1. In the implementation project, remove the -DEV suffix from the definition_asset_id version field in the cargo.toml file. For example: 1.0.0-DEV to 1.0.0.
2. Execute make release to release the implementation asset to Exchange.

Publish a Minor or Major Version Update (Definition and Implementation Update)

After you have Published a new split-model policy, you can update the definition and implementation assets for updates that require new parameters:

Update the definition asset:
1. Update the version in the exchange.json file of your definition project to 1.1.0.
2. Make changes to the gcl.yaml file.
3. make publish on the definition project to publish the development definition asset to Exchange.
Update the implementation asset:
1. In the implementation project, update the minor or major number of version in the cargo.toml file. For example: 1.0.0 to 1.1.0.
2. Update and add the -DEV suffix to the definition_asset_id version field in the cargo.toml. For example: 1.0.0-DEV to 1.1.0-DEV.
3. Execute make build-asset-files in the implementation project.
4. Code your policy logic and test locally.
5. Execute make publish to release the development implementation asset to Exchange for testing in lower environments.
6. Validate the policy works as expected. Complete steps D and E until testing is complete.
After validating the policy works as expected, release both assets to Exchange:
1. In the implementation project, remove the -DEV suffix from the definition_asset_id version field in the cargo.toml file. For example: 1.1.0-DEV to 1.1.0.
2. Execute make release to release the implementation asset to Exchange.

Develop Split Model Policies Locally Without Publishing to Exchange

Develop the policy definition:
1. Ensure the version in the exchange.json file is the correct version. For example: 1.0.0 for your first version.
2. Make changes to the gcl.yaml file.
3. Execute make release-local in the definition project.
Develop the policy implementation:
1. Add the -DEV suffix to the definition_asset_id version field in the cargo.toml and ensure it matches the definition asset version used in step one.
2. Execute make build-asset-files in the implementation project.
3. Code your policy logic and test locally.
4. Validate the policy works as expected. Complete steps C until testing is complete.
If you wish to distribute the policy locally as a production asset:
1. Remove the -DEV suffix from the definition_asset_id version field in the cargo.toml file. For example: 1.0.0-DEV to 1.0.0.
2. Execute make build to compile the implementation asset.
3. Distribute the policy assets as desired.