Where does AppBuilder cache dataservice schemas for validation?

I have a project in AppBuilder that rejected importing a dataservice (even though it imported fine to the data service repository) due to a JSON path being more than 64 character (apparently a secret limitation).

Now, having fixed the JSON body to have a shorter path, I still can not upload the new dataservice as the original version is still stuck in the validator and fails with the old JSON path specified.

In fact, I uploaded a completely different data service (using an .iads file) and that is rejected because of the initial dataservice that won't pass validation.

I can't seem to find the original in the databases anywhere, and I'm not familiar with where AppBuilder or the grid might be caching files/objects like this. But somehow I need to clear it out so I can continue adding more dataservices.

I was able to create a new project and upload the dataservice just fine, and I was able to add it to the root repository as well. It's just stuck in one particular project.

This is the error I found in the AppBuilder logs:

error: instance failed to match all required schemas (matched only 1 out of 2)
level: "error"
schema: {"loadingURI":"resource:/schemas/DatasourceSchema.json#","pointer":""}
instance: {"pointer":""}
domain: "validation"
keyword: "allOf"
matched: 1
nrSchemas: 2
reports: {"/allOf/0":[{"level":"error","schema":{"loadingURI":"resource:/schemas/DatasourceSchema.json#","pointer":"/allOf/0"},"instance":{"pointer":""},"domain":"validation","keyword":"oneOf","message":"instance failed to match exactly one schema (matched 0 out of 2)","matched":0,"nrSchemas":2,"reports":{"/allOf/0/oneOf/0":[{"level":"error","schema":{"loadingURI":"resource:/schemas/DatasourceParameterObject.json#","pointer":"/properties/key"},"instance":{"pointer":"/inputParameters/16/key"},"domain":"validation","keyword":"maxLength","message":"string "$.ItemMaster.IMH.SupSpecs[0].PkgingUnit.SupplierParty.PartyIDs.ID" is too long (length: 65, maximum allowed: 64)","value":"$.ItemMaster.IMH.SupSpecs[0].PkgingUnit.SupplierParty.PartyIDs.ID","found":65,"maxLength":64}],"/allOf/0/oneOf/1":[{"level":"error","schema":{"loadingURI":"resource:/schemas/DatasourceBI.json#","pointer":"/properties/typedef"},"instance":{"pointer":"/typedef"},"domain":"validation","keyword":"enum","message":"instance value ("generic") not found in enum (possible values: ["BI"])","value":"generic","enum":["BI"]}]}}],"/allOf/1":[]}

Find more posts tagged with

Accepted answers

All comments

Legacy Contributor

By way of update, wherever the original schema is being stored and stuck is not in the browser cache/storage and is persistent across sessions, as today we're still in the same predicament. Any ideas how or from where to remove the invalid schema so it stops trying to validate it when we upload anything else?

Legacy Contributor

Is this for the on prem version of App Builder? If so then we might have to discuss upgrading.

Legacy Contributor

Yep, it's on-premises, InforAppBuilder 12.0.19-201712051-30-953d39d-RELEASE from the Infor OS 12.0.30 installer. We haven't done the upgrade to 12.0.32 as we're in the middle of implementation and don't want to disrupt just yet.

For a workaround, I was able to simply clone the project to a new one, and import the dataservice file just fine (after shortening the path identifier that was causing the issue). But I couldn't find anyway to remove it from any cache or even find where it was being stored for that matter. So once something is imported with a long identifier, it seems like it just takes the whole project hostage.

On the flipside, if there's a place to increase the identifier length limit, that'd be great too. Especially since the whole body template is just stored in a single column in the database from what I can see. I couldn't really see a reason why the identifiers within the JSON text would be validated for length.

Legacy Contributor

Support and upgrades to the standalone App Builder product has been discontinued at this time. All enhancements to App Builder are now part of the Mongoose Framework. If you wish to migrate users from your purchased on prem license to Mongoose with App Builder, we can work with your sales rep to get that process started. If you are using the free user that came with Infor OS, then you would need to purchase Mongoose, and anything you have built on that on prem version, needs to be rebuilt.

Legacy Contributor

Or just work around the bugs.

Copyright © 2025 Infor. All rights reserved.