Yaml format supported for import

Blueprint and App Design
1

We have extracted a number of yaml files from a legacy code platforms however every time we try to import into blueprint we get an error. i have searched for a reference as to what structure are supported for yaml as source files for blueprint but no documentation can be found and no examples. Please confirm the acceptable format / structures and any limitations. also a working example would be helpful to test and use as a reference.

2

@Mr_Ketts We typically support all the YAMLs in compliance with OpenAPI spec.

https://petstore3.swagger.io/ is one example I am sharing here, that you can try.

Can you share more details on the YAML files you are trying?

Also, can you share what is the error you are encountering when importing the YAML?

3

I have been able to use YAML to import data structures. When I did it, it was not because I was trying to connect to a service, but because I had 250 properties defined on my case (from ideation) and I wanted to quickly reorganize those properties into classes. When I did it, I used a spreadsheet to work through what my target data model should be and then used copilot to generate a YAML to import the target data model into my blueprint so I could import it. (Co-pilot was not perfect.)

Here is an image (can’t attach a file) of what your YAML should look like to be accepted:

image
image866×1263 90.9 KB

You don’t have to include a description, but if you do, the properties will have that description.

if you get a data type wrong, for example using Text instead of string, the property may not import. I have also had cases with large YAMLs where I had to search for errors (thanks co-pilot) to get them to import.

If you see an object identified after doing your upload, you are half way there.

image
image543×407 12.4 KB

Your schema will be tested more thoroughly when hitting submit and other errors can prevent the import. This can be very aggravating.

Post upload, I recommend updating your labels for your fields as the labels and IDs will match what you imported. Doing this, you should be able to cleanly import your defined classes.

I also recommend doing a test import into another blueprint to verify what you are getting as you can’t delete embedded data classes should you decide you want to reimport after making corrections.

1 Like
4

Yaml Content 1 savings-ops-integration.yaml

integration:
name: savings-operations
description: Customer savings lifecycle covering account activation, standing instructions, and transfers.
owning_domain: SavingsAccounts
source_system: OnlineBankingApp
target_system: FineractSavings
dependencies:

  • ClientOnboarding
  • AccountingProcessorForSavings
    endpoints:
  • name: createSavingsAccount
    method: POST
    path: /fineract-provider/api/v1/savingsaccounts
    purpose: Configure savings product, link to client, and generate account number.
    request_schema_ref: schemas/savings-create.json
    response_schema:
    savingsId: integer
    accountNo: string
    status: string
    idempotent: true
  • name: activateSavingsAccount
    method: POST
    path: /fineract-provider/api/v1/savingsaccounts/{accountId}?command=activate
    purpose: Move account to ACTIVE once initial deposit cleared.
    idempotent: false
  • name: createStandingInstruction
    method: POST
    path: /fineract-provider/api/v1/accounttransfers/standinginstructions
    purpose: Capture recurring transfers using CalendarInstance schedules.
    request_schema:
    fromAccountId: integer
    toAccountId: integer
    amount: decimal
    recurrence: string
    response_schema:
    instructionId: integer
  • name: executeAccountTransfer
    method: POST
    path: /fineract-provider/api/v1/accounttransfers
    purpose: Real-time transfers between savings/loan accounts.
    request_schema_ref: schemas/account-transfer.json
    response_schema:
    transferId: integer
    status: string
    data_contract:
    tables:
  • savings_accounts
  • savings_standing_instructions
  • savings_transactions
  • account_transfers
    events:
  • SAVINGS_ACTIVATE
  • SAVINGS_TRANSFER_EXECUTED
    controls:
  • constraint: account balance >= transfer amount
  • constraint: standing instruction next_run_date maintained by scheduler
    sla:
    availability: 99.7%
    latency_p95_ms: 500

Yaml Content 2 charges-accounting-integration.yaml

integration:
name: charges-and-accounting
description: Integration for assessing charges/penalties and posting GL entries.
owning_domain: Charges
source_system: Loans|Savings|Clients services
target_system: AccountingRuleApiResource
batch_triggers:

  • cron: “0 */1 * * *”
    job: assess-due-charges
  • cron: “0 0 * * *”
    job: reconcile-ledger
    endpoints:
  • name: listCharges
    method: GET
    path: /fineract-provider/api/v1/charges
    purpose: Sync charge catalog for UI configuration.
    response_schema:
    charges: array
  • name: applyCharge
    method: POST
    path: /fineract-provider/api/v1/charges/{chargeId}?command=applyCharge
    purpose: Apply configured charge to an entity (loan/savings/client).
    request_schema:
    amount: decimal
    dueDate: date
    entityType: string
    entityId: integer
  • name: createAccountingEntry
    method: POST
    path: /fineract-provider/api/v1/gljournalentries
    purpose: Post manual adjustments when automated processors fail.
    request_schema_ref: schemas/gl-entry.json
    data_contract:
    tables:
  • charges
  • charge_applications
  • accounting_entries
    events:
  • CHARGE_ASSESSED
  • GL_POSTED
    controls:
  • dual_control_required: true
  • audit_log: immutable business_events payload
    sla:
    availability: 99.9%
    latency_p95_ms: 700