feat(fortimanager): add FortiManager Integration Model and Studio Project - #109
Merged
Merged
Conversation
FortiManager's entire API is a single JSON-RPC 2.0 endpoint (POST /jsonrpc), not per-resource REST paths, so this spec exposes one generic jsonRpcCall operation with worked examples for common patterns (policy/ object CRUD, device management, install). Scoped to FortiManager >= 7.2.2 so Bearer-token auth can be used, since older releases' session-based JSON-RPC auth threads a token through the request body and can't be expressed as an OpenAPI security scheme.
Add a FortiManager Studio Project with 7 workflows -- one per the OpenAPI spec's request-body examples (status, ADOM/device inventory, address object, policy read, device add, config install). Each workflow is a thin two-task wrapper around the Integration Model's single jsonRpcCall operation, with its input schema mirroring the request body directly (id/method/params) so every adapter-task incoming field is a bare $var.job.X reference -- avoiding the nested-$var-doesn't-resolve pitfall for the array/object-shaped params field. Hand-authored against the OpenAPI schemas, not yet built/run against a live FortiManager -- flagged in the README pending that verification.
…ields Live-testing against a real Itential Platform (import + workflow validation) surfaced that OpenAPI-Integration-Model-backed adapter tasks expose a POST operation's JSON request body as a single requestBodyPayload + bodyContentType pair, not flat per-property inputs the way GET path/query parameters work. The first draft wired id/method/ params directly and failed validation with "Cannot find match for input" on all five fields. Fix: collapse the job input schema to one `body` object (id/method/params, still 1:1 with the OpenAPI request schema) and point requestBodyPayload at $var.job.body. All 7 workflows now import and validate cleanly against a live platform with zero errors/warnings. Documented the requestBodyPayload/bodyContentType convention in the README for future specs with a JSON request body.
Rename info.title from 'FortiManager JSON API' to 'FortiManager' (no API suffix), rename the spec file to match, and use a real vendor version string for x-vendor-api-version instead of descriptive text. Re-verified both imports against a live Itential Platform instance.
Remove a caveat callout about the jsonRpcCall task not having been exercised against a real backend, and a sentence narrating how a detail was discovered during validation. State what's included, not process/testing narration.
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fortinet/FortiManager/OpenAPIs/fortimanager-latest.json— single generic JSON-RPC endpoint (POST /jsonrpc), covering policy/object config, device inventory/management, and provisioningTest plan