The WOPI Validator behavior and the HostFrameIntegration errors are driven entirely by how the WOPI host and host page are configured. The context available here only covers how the Validator works at a high level and what Microsoft requires for launch, so the guidance below focuses on getting the Validator into a clean, fully‑exercised state and on what must be true in general for HostFrameIntegration to pass.
- Why tests are skipped
The WOPI Validator runs different categories and individual tests based on:
- Which WOPI operations are implemented and correctly advertised in WOPI discovery.
- Which features are enabled on the host page (for example, whether certain placeholders or capabilities are present).
- The test category selected via
VALIDATOR_TEST_CATEGORY.
From the documentation:
- The Validator is a Microsoft 365 for the web application discovered via WOPI discovery and triggered through the
view or getinfo actions on the .wopitest extension.
- New tests are added regularly, and some tests are applicable only if the host supports specific operations such as
PutRelativeFile, CreateChildFile, CreateChildContainer, RenameFile, PutUserInfo, or proof key validation.
As a result, tests are skipped when:
- The corresponding operation or feature is not advertised in discovery for the
.wopitest extension, or
- The Validator determines that the scenario is not applicable to the current configuration.
To maximize coverage and avoid unexpected skips, ensure that:
- The
.wopitest extension is present in discovery with the same actions and capabilities as the Office file types being integrated.
- Any optional operations that are implemented (for example
PutRelativeFile, RenameFile, PutUserInfo, proof keys) are correctly advertised so their test groups can run.
If integrating only with Microsoft 365 for mobile and not Office for the web, the documentation notes that VALIDATOR_TEST_CATEGORY can be set to OfficeNativeClient to run only the mobile‑relevant subset of tests. Using other categories or omitting this setting can change which tests appear or are skipped.
- HostFrameIntegration failures
For launch, Microsoft requires that all applicable HostFrameIntegration tests pass. The documentation lists HostFrameIntegration as the first mandatory category whose screenshot must be provided before verification testing starts.
HostFrameIntegration tests validate that:
- The host page correctly integrates the Office frame (for example, iframe hosting, query parameters, and placeholders such as
UI_LLCC and DC_LLCC when used).
- Required headers and behaviors are present when Office for the web loads the document through the host page.
The documentation explicitly calls out that the ValidLanguagePlaceholderValues test may be skipped if the host is not using the UI_LLCC or DC_LLCC placeholders. If those placeholders are used, the test must pass; if they are not used, the skip is expected and not a failure.
Given the three specific errors shown in the screenshots (all related to access tokens and TTL), the HostFrameIntegration issues are likely caused by:
-
access_token being passed via HTTP GET instead of HTTP POST on the action URL.
-
access_token_ttl being missing, zero, or not set to a valid future timestamp (milliseconds since 1/1/1970) when the token expires.
To resolve these:
- Ensure that the host page posts the
access_token and access_token_ttl to the action URL using HTTP POST, not GET.
- Set
access_token_ttl to a non‑zero Unix epoch timestamp in milliseconds that represents a time in the future when the token will expire.
- Required state before Microsoft verification
Before submitting for CSPP launch, the documentation requires that all applicable Validator categories pass, including:
- HostFrameIntegration
- BaseWopiViewing
- CheckFileInfoSchema
- EditFlows
- Locks
- PutRelativeFile or PutRelativeFileUnsupported
- RenameFile* variants (if
RenameFile is supported)
- FileVersion
- PutUserInfo (if supported)
- ProofKeys (if proof key validation is implemented)
Microsoft will not start verification until these categories are passing in the Validator. Any skipped tests that are applicable to supported features must be addressed by correcting discovery or implementation so they run and pass.
- Additional validation and troubleshooting
The documentation emphasizes:
- Always run the Validator in the Microsoft 365 for the web test environment to use the latest Validator version.
- The Validator will exercise operations like
PutFile and may create new files or containers via PutRelativeFile, CreateChildFile, and CreateChildContainer. If cleanup fails due to WOPI errors, test artifacts may remain and can cause later runs to fail; these must be cleaned up manually.
- Before reporting issues to Microsoft, ensure that all Validator tests are passing and review the common implementation problems and known issues.
- Automation and alternative execution
If it is useful to iterate faster while debugging HostFrameIntegration and skipped tests, the same test suite can be run via:
- The open‑source validation tool (
wopi-validator-core), which does not depend on Microsoft 365 for the web infrastructure and is suitable for automated or offline testing.
- The Python‑based CLI (
wopi-validator-cli-python), which uses the getinfo action URL from WOPI discovery to execute the same test cases as the hosted Validator.
These tools can help confirm that changes to token handling, discovery, or host page behavior resolve the HostFrameIntegration failures before re‑running in the hosted Validator.
Because the available documentation does not cover Oracle WebCenter Content–specific configuration, any WCC‑specific endpoints, authentication plumbing, or reference implementations are outside the scope of the context here. However, once WCC exposes a WOPI‑compliant host and host page that satisfy the requirements above, the Validator behavior and HostFrameIntegration tests will align with the documented expectations.
References: