Pushing provider organization data

Use the AMU to push the provider organization data to the Management server.

About this task

Pushing the provider organization data uploads the ported OAuth Providers, draft APIs, draft products, configured gateway services, and published products to the Management server.

Procedure

  1. Log in to the API Manager user interface as an Owner or Administrator of the provider organization.
    Important: You must be logged in as the Owner or Administrator of the provider organization whose data you will push.
    Syntax:
    ./apicm login -s <RI_instance_host_name> -r provider/default-idp-2 -u <username_on_RI>
    You can determine the <RI_instance_host_name> by logging in to your Reserved instance. In the browser's address bar, note down the host name from the URL.
    Example:
    ./apicm login -s manager.e113-eef3fa4e.us-south.apic.test.cloud.ibm.com -r provider/default-idp-2 -u RI_Porg_User
    Table 1. login parameters for Provider organizations
    Parameters Description
    <RI_instance_host_name> Required. The API Manager URL endpoint on the Management server for communication with the API Manager user interface. For a Reserved instance, this is the host name of the instance.
    You can determine the host name by logging in to your Reserved instance. In the browser's address bar, note down the host name from the URL as in the following example:
    https://<RI_instance_host_name>/manager/
    --realm provider/identity_provider Required. For a Reserved instance, use default-idp-2 as the identity_provider..
    -u <username_on_RI> The username for logging in to the Reserved instance's provider organization; the user must be the owner or an admin of the provider organization.
  2. Push the data for the provider organization.

    In the same directory where you ran the archive:unpack-v10 command, run the following command to push the ported data to your API Manager. See the parameters in Table 2 as well as the usage notes that follow the table.

    Syntax:
    ./apicm archive:push-v10 <RI_instance_host_name> cloud-v10/provider-orgs/<pOrg_name> [optional flags]
    Example (optional flags are omitted):
    ./apicm archive:push-v10 manager.e113-eef3fa4e.us-south.apic.test.cloud.ibm.com cloud-v10/provider-orgs/production_Org
    Table 2. archive:push-v10 parameters for provider organizations
    Parameters Description
    <RI_instance_host_name> Required. The API Manager URL endpoint on the Management server for communication with the API Manager user interface. For a Reserved instance, this is the host name of the instance.
    You can determine the host name by logging in to your Reserved instance. In the browser's address bar, note down the host name from the URL as in the following example:
    https://<RI_instance_host_name>/manager/
    cloud-v10/provider-orgs/<pOrg_name> Required. The location of your provider org within the /cloud-v10 file hierarchy you created when you ran unpacked the data archive; for example: 
    cloud-v10/provider-orgs/production_Org
    --catalogs=<list_of_names> Optional. Push data for only the specified catalogs if you don't want to push the entire provider organization. Use this parameter to specify the names of the catalogs you want to push (to specify multiple catalogs, use a comma-separated list):
    ./apicm archive:push-v10 <api-manager-ui-endpoint> cloud-v10/provider-orgs/<pOrg_name>
              --catalogs=<catalog_name1,catalog_name2,catalog_name3>
    --spaces=<list_of_names> Optional. Push data for only the specified spaces if you don't want to push the entire provider organization. The --catalogs parameter must also be specified, and exactly one catalog must be specified. Use this parameter to specify the names of the spaces you want to push (to specify multiple spaces, use a comma-separated list). For example: 
    ./apicm  archive:push-v10 <api-manager-ui-endpoint> cloud-v10/provider-orgs/<pOrg_name> 
              --catalogs=<catalog_name>
              --spaces=<space_name1>,<space_name2>,<space_name3>
    --products=<list_of_name:version_pairs> Optional. Push data for only the specified products if you don't want to push the entire provider organization. The --catalogs parameter must also be specified, and exactly one catalog must be specified. If spaces are enabled on the catalog, then the --spaces parameter must also be specified, and exactly one space must be specified. Use this parameter to specify the names and versions of the products that you want to push (to specify multiple products, use a comma-separated list of name:version pairs as shown in the following examples.

    Example: catalog with spaces

    ./apicm archive:push-v10 <api-manager-ui-endpoint> cloud-v10/provider-orgs/<pOrg_name>
              --catalogs=<catalog_name> --spaces=<space_name>
              --products=<prod_name1>:<prod_version1>,<prod_name2>:<prod_version2>,<prod_name3>:<prod_version3>

    Example: catalog without spaces:

    ./apicm archive:push-v10 <api-manager-ui-endpoint> cloud-v10/provider-orgs/<pOrg_name>
              --catalogs=<catalog_name>
              --products=<prod_name1>:<prod_version1>,<prod_name2>:<prod_version2>,<prod_name3>:<prod_version3>
    --dry-run Optional. Perform a dry run to test the Admin org migration output.

    This option creates a project directory similar to cloud-v10, but titled .workdir-<api-manager-ui-endpoint> where you can view how the data will be loaded into your new system. The option also displays the objects that will fail due to existing already or missing dependencies. Use this option to view the resolved URLs for where the data will be loaded, without creating resources on the new system. See Migration troubleshooting.

    ./apicm archive:push-v10 <api-manager-ui-endpoint> cloud-v10/provider-orgs/<pOrg_name>
              --dry-run
    --no-drafts Optional. Do not push any draft APIs or products (draft objects are objects that have not been published).
    ./apicm archive:push-v10 <api-manager-ui-endpoint> <path_to_provider_org>
              --no-drafts

    This option can be used with or without the --catalogs parameter.
    --drafts-only Optional. Only push ported draft APIs and products, and do not push any published APIs or products (draft objects are objects that have not been published).
    ./apicm archive:push-v10 <api-manager-ui-endpoint> <path_to_provider_org>
              --drafts-only

    This option cannot be used with the --catalogs or --no-drafts parameters.
    --overwrite Optional. Overwrite any existing draft products, draft APIs, published products and their APIs, and OAuth Providers that are already on the deployment. If you set this parameter to false, these artifacts will be left intact.
    --move-subscriptions Optional. When this option is used, the subscriptions associated with v5-compatible-API-based products that were ported to API DataPower Gateway-based products and successfully pushed to the API Connect deployment will have their subscriptions moved to the new products, and the original v5-compatible-API-based products will be retired. This option can also be used on subsequent archive:push-v10 commands to move the subscriptions even after the migrated products are published. Using the --catalogs, --spaces, and --products parameters with the --move-subscriptions parameters lets you narrow the set of products to have their subscriptions moved.
    Usage notes:
    • On Windows: open a command window with Administrator privileges, and omit the "./" from the command.

    • Run the archive:push-v10 command in the same directory where you ran the archive:unpack-v10 command, and always push the ported data back to the same deployment where you extracted the data.

    • The login command obtains a token that expires after 8 hours.

      If the token expires while the archive:push-v10 command is running, the AMU generates errors. In this case, log in again and re-run the push command. The token is refreshed every time you log in. For more information, see migration_troubleshooting.html#migration_troubleshooting__token_expire.

    • The archive:push-v10 command only pushes only the following ported objects: OAuth Providers, draft APIs, draft products, configured gateway services, and published products.

  3. Test your newly ported products and APIs to make sure they are working as expected.

    If necessary make changes and push the updates to your API Connect deployment.