Ingesting Content into Target

Ingestion Process in Content Transfer Tool

Follow the steps below to ingest your migration set from the Content Transfer Tool:

NOTE

Did you remember to log a support ticket for this ingestion? See Important Considerations Before Using Content Transfer Tool for that and other considerations to help make the ingestion successful.

  1. Go to Cloud Acceleration Manager. Click on your project card and click on the Content Transfer card. Navigate to Ingestion Jobs and click on New Ingestion

    image

  2. Review the ingestion checklist and ensure that all the steps have been completed. These are necessary steps to ensure a successful ingestion. You will be able to proceed to the Next step only if the checklist has been completed.

    image

  3. Provide the required information to create a new ingestion.

    • Select the migration set that contains the extracted data as the Source.
      • Migration Sets will expire after a prolonged period of inactivity, so it is expected that the ingestion occurs relatively soon after the extraction has been performed. Review Migration Set Expiry for details.
    • Select the destination environment. This is where the content of the migration set will be ingested. Select the tier. (Author/Publish). Rapid Development Environments are not supported.
    NOTE

    The following notes apply to ingesting content:
    If the source was Author, it is recommended to ingest it into the Author tier on the target. Similarly, if source was Publish, target should be Publish as well.
    If the target tier is Author, the author instance will be shutdown during the length of the ingestion and will be unavailable to users (for example, authors or anyone performing maintenance, etc.). This is to protect the system, and prevent any changes which could either be lost or cause an ingestion conflict. Please ensure that your team is aware of this fact. Also note that the environment will appear hibernated during the author ingestion.
    You can run the optional pre-copy step to significantly speed up the ingestion phase. Refer to Ingesting with AzCopy for more details.
    If ingesting with pre-copy is used (for S3 or Azure Data Store), it is recommended to run Author ingestion first alone. This will speed up the Publish ingestion when it is run later.
    Ingestions do not support a Rapid Development Environment (RDE) destination. They will not appear as a possible destination choice, even if the user has access to it.

    IMPORTANT

    The following important notices apply to ingesting content:
    You will be able to initiate an ingestion to the destination environment only if you belong to the local AEM administrators group on the destination Cloud Service author service. If you are unable to start an ingestion, refer to Unable to Start Ingestion for more details.
    If the setting Wipe is enabled before ingestion, it deletes the entire existing repository and creates a new repository to ingest content into. This means that it resets all settings including permissions on the target Cloud Service instance. This is also true for an admin user added to the administrators group. You will need to be re-added to the administrators group in order to start an ingestion.

  4. Click on Ingest

    image

  5. You can then monitor the Ingestion phase from the Ingestion Jobs list view and use the ingestion’s action menu to view the log as the ingestion progresses.

    image

  6. Click on (i) button in the row to get more information about the ingestion job. You can see the duration of each step of the Ingestion when it is executing or completed by clicking on … and then on View durations. The information from the extraction is also shown to realize what is being ingested.

    image

Top Up Ingestion

The Content Transfer Tool has a feature that supports differential content top-up where it is possible to transfer only changes made since the previous content transfer activity.

NOTE

After the initial content transfer, it is recommended to do frequent differential content top-ups to shorten the content freeze period for the final differential content transfer before going live on Cloud Service. If you have used the pre-copy step for the 1st full ingestion, you can skip pre-copy for subsequent top-up ingestions (if the top-up migration set size is less than 200GB) because it may add time to the entire process.

Once the ingestion process is complete, to ingest the delta content you will need to run a Top-Up Extraction and then use the top-up ingestion method.

You can do this by creating a new Ingestion Job and ensure that Wipe is disabled during the Ingestion phase, as shown below:

image

Troubleshooting

CAM Unable to Retrieve the Migration Token

The automatic retrieval of the migration token may fail for different reasons, including you setting up an IP allow list via Cloud Manager on the target Cloud Service environment. In such scenarios you will see the following dialog when you attempt to start an ingestion:

image

You will need to retrieve the migration token manually by clicking on the “Get token” link on the dialog. This will open another tab that displays the token. You can then copy the token and paste it into the Migration token input field. Now, you should be able to start the ingestion.

NOTE

The token will be available to users who belong to the local AEM administrators group on the destination Cloud Service author service.

Unable to Start Ingestion

You will be able to initiate an ingestion to the destination environment only if you belong to the local AEM administrators group on the destination Cloud Service author service. If you don’t belong to the AEM administrators group, you will see an error as shown below when you try to start an ingestion. You can either ask your administrator to add you to the local AEM administrators or ask for the token itself, which you can then paste into the Migration token input field.

image

Unable to reach migration service

After an ingestion is requested, a message like the following may be presented to the user: “The migration service on the destination environment is currently unreachable. Please try again later or contact Adobe support.”

image

This indicates that the Cloud Acceleration Manager was unable to reach the target environment’s migration service to start the ingestion. This can happen for a number of reasons.

NOTE

The “Migration token” field is shown because in a few cases retrieving that token is what is actually disallowed. By allowing it to be manually provided, it may allow the user to start the ingestion quickly, without any additional help. If the token is provided, and the message still appears, than retrieving the token was not the problem.

  • AEM as a Cloud Service maintains the environment state, and occasionally may need to restart the migration service for a number of normal reasons. If that service is restarting, it cannot be reached, but will be available soon.
  • It is possible another process is being run on the instance. For instance, if Release Orchestrator is applying an update, the system may be busy and the migration service regularly unavailable. That, and the possibility of corrupting the stage or production instance, is why pausing updates during an ingestion is very strongly recommended.
  • If an IP Allowlist has been applied through Cloud Manager, it will block Cloud Acceleration Manager from reaching the migration service. An IP address cannot be added for ingestions because its address is very dynamic. Currently, the only solution is to disable the IP allow list while the ingestion is running.
  • There may be other reasons that need investigation. If the ingestion still continues to fail, please contact Adobe Customer Care.

Automatic Updates through Release Orchestrator is still enabled

Release Orchestrator automatically keeps environments up to date by applying updates automatically. If the update is triggered when an ingestion is being performed, it can cause unpredictable results including the corruption of the environment. That is one of the reasons a support ticket should be logged before starting an ingestion (see “Note” above), so that temporarily disabling the Release Orchestrator can be scheduled.

If Release Orchestrator is still running when an ingestion is being started, the UI will present this message. You may choose to continue anyway, accepting the risk, by checking the field and pressing the button again.

NOTE

Release Orchestrator is now being deployed to Development environments, so pausing updates on those environments should be done as well.

image

Top-up Ingestion Failure

A common cause of a Top-up Ingestion failure is a conflict in node ids. To identify this error, download the ingestion log using the Cloud Acceleration Manager UI and look for an entry like the following:

java.lang.RuntimeException: org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0030: Uniqueness constraint violated property [jcr:uuid] having value a1a1a1a1-b2b2-c3c3-d4d4-e5e5e5e5e5e5: /some/path/jcr:content, /some/other/path/jcr:content

Each node in AEM must have a unique uuid. This error indicates that a node that is being ingested has the same uuid as one that already exists at a different path on the target instance.
This can happen if a node is moved on the source between an extraction and a subsequent Top-Up Extraction.
It can also happen if a node on the target is moved between an ingestion and a subsequent top-up ingestion.

This conflict must be resolved manually. Someone familiar with the content must decide which of the two nodes must be deleted, keeping in mind other content that references it. The solution may require that the top-up extraction is done again without the offending node.

What’s Next

Once you have completed Ingesting Content into Target, you can view logs of each step (extraction and ingestion) and look for errors. See Viewing Logs for a Migration Set to learn more.

On this page