An Oracle BI Publisher export/import workflow starts with a simple request: move one reviewed report while keeping enough evidence to check and recover the change. With Fusion Toolkit’s 3.2.0 preview, you can ask AI Administrator to export the report, inspect the destination, and prepare an import for your review. You then check object existence, content, and report behavior separately.
Synthetic illustration: All prompts, profile names, and catalog names below illustrate a test workflow. They are not a recorded session or evidence of a successful migration.
Run it directly from the CLI
You can carry out this workflow in a terminal without an AI agent. Use the matching Fusion Toolkit 3.2.0 preview, a valid licence, and the existing report-source and report-test profiles. Open Bash or WSL in the installed fusion-toolkit-ai-administrator folder, with fusion-toolkit on your PATH. The ai-admin command group runs the documented operations directly; it does not start a model session. Check each command’s returned environment and origin against the intended source or destination.
Export the source report and check its archive
Create a request file for the exact report, then execute the read:
fusion-toolkit --version
fusion-toolkit ai-admin docs status
cat > export-source.json <<'JSON'
{
"schema_version": "3.0",
"operation_id": "bi.catalog.export",
"body": {
"reportAbsolutePath": "/Custom/Training/InvoiceCheck.xdo"
},
"output_file": "InvoiceCheck-source.catalog",
"response_limits": {"max_bytes": 8388608}
}
JSON
fusion-toolkit --profile report-source --output json \
ai-admin api execute --request export-source.json
On success, the command saves InvoiceCheck-source.catalog and InvoiceCheck-source.catalog.manifest.json beside the request file. The manifest records the exported bytes and SHA-256 checksum. This example caps the archive at 8 MiB. Use new filenames for another export; existing artifacts are not overwritten.
Check the saved bytes against that manifest locally:
python3 - <<'PY'
import hashlib
import json
from pathlib import Path
archive = Path('InvoiceCheck-source.catalog')
manifest = json.loads(Path(str(archive) + '.manifest.json').read_text())
actual = hashlib.sha256(archive.read_bytes()).hexdigest()
if actual != manifest['sha256']:
raise SystemExit('Archive checksum mismatch; stop before import')
print('SHA-256 matches:', actual)
PY
Inspect the destination and save its existing version
Read the exact destination before planning an import:
cat > inspect-target.json <<'JSON'
{
"schema_version": "3.0",
"operation_id": "bi.catalog.exists",
"body": {
"reportObjectAbsolutePath": "/Custom/Training/InvoiceCheck.xdo"
}
}
JSON
fusion-toolkit --profile report-test --output json \
ai-admin api execute --request inspect-target.json
If the destination exists, preserve it before replacement. Create export-before.json using the same report path and a separate local archive name:
cat > export-before.json <<'JSON'
{
"schema_version": "3.0",
"operation_id": "bi.catalog.export",
"body": {
"reportAbsolutePath": "/Custom/Training/InvoiceCheck.xdo"
},
"output_file": "InvoiceCheck-before.catalog",
"response_limits": {"max_bytes": 8388608}
}
JSON
fusion-toolkit --profile report-test --output json \
ai-admin api execute --request export-before.json
Check this backup against its own manifest using the checksum check above with InvoiceCheck-before.catalog. Retain both files separately from the source export. If the destination is absent, confirm its parent folder instead. Stop on an access error or incomplete read. Check data models, templates, connections, and permissions separately; one report export does not establish that its dependencies are present.
Plan and approve the exact import in the terminal
Bind the source archive to the destination. The Toolkit reads and base64-encodes the local file and includes its checksum in the immutable plan:
cat > import-target.json <<'JSON'
{
"schema_version": "3.0",
"operation_id": "bi.catalog.import",
"body": {
"reportObjectAbsolutePathURL": "/Custom/Training/InvoiceCheck.xdo",
"objectType": "xdo"
},
"input_files": {
"objectZippedData": {
"path": "InvoiceCheck-source.catalog",
"encoding": "base64",
"max_bytes": 8388608
}
}
}
JSON
fusion-toolkit --profile report-test --output human \
ai-admin api plan --request import-target.json
This prepares a plan and does not import the report. Review its full destination, current state, archive checksum, proposed change, documentation, recovery evidence, and verification limits. Copy the actual plan_id from that output into the following command only after review:
fusion-toolkit --profile report-test --output human \
ai-admin api apply --plan REPLACE_WITH_IMPORT_PLAN_ID
Run apply interactively and enter the exact confirmation phrase it displays only if you approve that plan. No chat approval is needed for this terminal route. A changed file, target, or expired ten-minute plan requires a new plan and review. Investigate an uncertain write before any further import.
Verify existence, content, and report behavior separately
Run the inspect-target.json read again after import. Re-export from report-test using a new output_file such as InvoiceCheck-after.catalog, and verify that archive against its own manifest. Compare it with the reviewed source; a byte difference needs inspection because archive packaging can also differ. Existence verification alone does not establish identical content. Run the report with suitable test parameters and confirm its model, templates, and results. Restore an existing version only through a separately reviewed import of the preserved backup.
The following AI Administrator walkthrough carries out the same stages conversationally.
Start the conversation in the installed workspace
Open the installed AI Administrator workspace and start a compatible agent there, such as Codex, Claude Code, or Gemini CLI. It should read the workspace’s bundled instructions and use the matching 3.2.0 preview Toolkit. You need a valid Toolkit licence and existing configured Oracle profiles; keep passwords and licence material out of the conversation.
Here, report-source identifies the source and report-test identifies a separate test destination. Have the assistant identify each profile’s declared environment, site address, and Oracle account. Profile names alone do not establish where a request will go. The assistant should find the current documented operations and disclose any reliance on dated, cached documentation.
The source account needs permission to inspect and export the report. The destination account needs the appropriate catalog write privileges. Running the report also requires access to its referenced objects, as Oracle explains in its catalog permissions reference.
Ask for one export and its checksum
For this illustration, InvoiceCheck means the report at /Custom/Training/InvoiceCheck.xdo. Establish that exact path before using its short name:
Export InvoiceCheck from report-source and keep its checksum.
AI Administrator should locate the documented export operation and save a local archive with a companion record containing its size, SHA-256 checksum, and source information. A checksum is a fingerprint of the exported bytes. Export reads the source; it does not import anything into the destination.
If several reports match the name, the assistant should ask which path you mean. If the report cannot be read, it should explain the access or compatibility problem. It should use a new local filename when an export already exists and respect the selected file-size limit.
Once the export finishes, ask:
Check that the saved InvoiceCheck archive matches its recorded checksum. Tell me where both files are saved and which source report they came from.
A match establishes that the saved bytes agree with the export record. It does not establish that the report is correct. An incomplete export or failed check needs investigation before promotion.
For background on the surrounding tasks, see BI Publisher report management. Oracle’s Fusion Applications reporting service guidance provides service context; the assistant should select the current operation supported by your environment.
Inspect the destination and preserve the previous version
A report and its data model are separate catalog objects. Before import, check the destination folder, model reference, templates, connections, and required permissions. Exporting one report is not evidence that all its dependencies will move with it.
Continue with:
Inspect /Custom/Training/InvoiceCheck.xdo in report-test. Preserve any existing version in a separate export with its checksum, check the required dependencies, and prepare an import plan for the reviewed source archive.
The assistant should inspect the exact destination. If a report is already present, its saved export becomes a recovery artifact. Check that this backup completed and can be identified independently of the source archive. Agree who would restore it and how restoration would be verified.
If the destination is absent, the assistant should explain the proposed creation and confirm the parent folder. A permission error does not establish absence. Missing dependencies or an incomplete destination read should remain visible limitations, with further work identified before approval.
Review the complete import plan before approving
Preparing a plan does not perform the import. AI Administrator should display the complete current plan before asking you to approve it. Review:
- The destination environment, site address, Oracle account, and exact request and catalog path.
- The full current state with secrets hidden, the proposed report archive, and its checksum.
- Whether the change creates or replaces an object, its business impact, and the preserved recovery version.
- The Oracle documentation source and release, its checksum, and any compatibility limitations.
- The planned checks, their limits, and the plan’s reference, fingerprint, and expiry.
The plan binds the reviewed file to that specific destination. If the archive, target, or conditions change, the assistant must prepare and display a new plan. Preview plans expire after ten minutes and can be used once.
Only after reviewing that complete current plan, an approval could be:
I approve the displayed import plan for InvoiceCheck in report-test using the reviewed source archive.
The assistant should apply that exact plan and report the outcome. The earlier request to prepare it is not approval. If the outcome is uncertain after a timeout, inspect the destination before considering another import; repeating the write could replace an object again.
Ask three separate verification questions
Start with existence:
Check whether InvoiceCheck exists at the planned destination path. Explain exactly what the import’s built-in verification establishes.
The built-in check establishes that an object exists at that path. An older report may already have existed there, so this result alone cannot establish that the reviewed content arrived.
Then ask about content:
Export the destination report to a new local file. Compare its checksum with the reviewed source export and investigate any difference.
Equal checksums establish byte equality between those archives. Different checksums require closer inspection: archive packaging can differ even when report definitions are equivalent. The assistant should explain the evidence and any unresolved comparison, without declaring every mismatch a failed migration.
Finally, ask about behavior:
Check the destination’s model reference, required parameters, and permissions, then run a small representative test report using suitable test data. Separate what passed from anything you could not check.
A successful report run supports that particular test case. It does not certify every parameter combination, user role, or downstream use. If a proposed test would create scheduled work or write output remotely, that change needs its own displayed plan and approval. See automating BI Publisher report execution for the execution workflow.
Keep the source export, previous destination version, approved plan, and the three sets of verification evidence together in your change record. Start with the Fusion Toolkit documentation to prepare the workspace and profiles for your own test promotion.