Saving JSON based documents with 2026.06

matthias-modular-brook · July 28, 2026, 10:16am

Hi there!

We are currently migrating our project AASH (Access Ablöse) to 2606.06 and running into problems creating new documents from JSON and saving them.
What we are doing:

We create the JSON from a Pojo:

String jsonInput = createA12Entity(mainTable, valueExtractor, "", report).getJsonString();

transform it into a document

final DocumentV2 rawDocument = documentSupport.convertJSONToDocument(
                                documentModelId, new StringReader(jsonInput));
final DocumentV2 document = computationService.computeDocument(rawDocument);

and finally save it:

private DataServicesDocument createNewDoc(DocumentV2 document) {
	return documentService.create(document, GERMAN);
}

The create call fails here because the data service is complaining that the __meta field is missing.
According to Claude the validation/computation can only run on runtime models and the document we pass here does not seem to have that header.

Caused by: java.lang.IllegalArgumentException: The set of fields does not contain </__meta>.
	at com.mgmtp.a12.kernel.core.rt._31_1.internal.meta.MetaDataValidierungIntern.getUniqueName(MetaDataValidierungIntern.java:177)

I have attached more logs too, but what am I missing? I have seen the MetaDataUtil, but I’m not sure how to use it and the docs did not tell me anything.

documen-creation-log.txt (13.7 KB)
AccessA12Entity.java (3.5 KB)

EDIT 1:

I am just realizing that the same error happens for documents I create via the frontend save button for a new document of the app.

Caused by: java.lang.IllegalArgumentException: The set of fields does not contain </__meta>.
	at com.mgmtp.a12.kernel.core.rt._31_1.internal.meta.MetaDataValidierungIntern.getUniqueName(MetaDataValidierungIntern.java:177)
	at com.mgmtp.a12.kernel.core.rt._31_1.internal.core.CalculationCommand.lambda$getDataWithoutEntitiesNotNeededForCalculations$2(CalculationCommand.java:107)
	at com.mgmtp.a12.kernel.core.rt._31_1.internal.util.FilteringIterator.initNext(FilteringIterator.java:67)
	at com.mgmtp.a12.kernel.core.rt._31_1.internal.util.FilteringIterator.<init>(FilteringIterator.java:61)

stefan-cold-haze · July 28, 2026, 11:58am

The __meta group is missing in your models because they were not passed through the Workspace Converter Framework before the import into Data Services. This is a breaking change of 2026.06, not a problem in your code.

Have a look at Data Services No Longer Expands Models at Runtime. Until 2025.06 Data Services expanded the models on every import and added the meta-data groups. Since 2026.06 this is done by the Workspace Converters, and Data Services expects the models already in runtime format.

What happens in your case: Data Services adds the Document Metadata (docRef, modelRef, creator, createdAt, …) to the document before computation and validation run. The computation then resolves every entity of the given data against the Document Model, and /__meta is not part of your model. That is the IllegalArgumentException you see in MetaDataValidierungIntern.getUniqueName.

Your EDIT 1 fits that. The save button of the frontend ends in the same documentService.create(...), so createA12Entity() and convertJSONToDocument() are not the cause.

Hint: You can check it quickly. Load one of your Document Models from the model store of the running application and look for a top-level group named __meta. If it is not there, the model is not in runtime format.

What you have to do

Convert your Document, Combination and Transformer Models with the Workspace Converter Framework before the import. I would recommend the approach of the Project Template, where the runtime models are build artifacts and not under version control:
```
dependencies {
    wcfCli a12Libs.dataservices.wcf.cli
    wcfCli a12Libs.rmc.conversion
}

tasks.register('convertModels', Exec) {
    // java -cp <wcfCli> com.mgmtp.a12.dataservices.wcf.WcfCli \
    //      import/models build/wcf-output -c <conversion-*.jar>
}
```
The complete example is part of the migration entry.
Use importRuntimeModels(InputStream) instead of importModelBulk(InputStream) and drop ModelBulkImporter.doImport, see Data Services Public API Changes.
If you import models at runtime from your own code, integrate the conversion there. The pipeline and the converters are described in Workspace Conversion Framework. Custom converters implement WorkspaceConverter and are picked up via @WcfConverter(order=…, description=…).

Afterwards your code should work unchanged, because the converted model contains the __meta group that Data Services fills.

Important: MetaDataUtil does not help here. There is also DocumentMetadataUtils.removeMetadataGroups(DocumentV2) in dataservices-core, but that one is meant for Kernel operations on models without __meta (Mapping sources for example). On documentService.create() you want the metadata to be persisted, not removed.

Note: As far as I am aware of, in the source models the __meta group is only present if the SME added it while a UI model editor was used, and that can be suppressed in the Workspace Settings under Document Metadata > Show Document Metadata in UI Models. Since 2026.06 the Converters create the runtime format anyway, so only the conversion step matters.

I would also recommend to keep the source models under version control and to convert them into a build directory. The migration entry mentions it as well, model migration on runtime models is not guaranteed to work in the future.

Small reminder because of the topic title: the release line is 2026.06

For the other Data Services changes of this release, see Data Services > Migration Instructions.

matthias-modular-brook · July 30, 2026, 11:02am

Whom it may help… here is the corresponding converter. Make sure you have the deps

        version('wcf', '1.1.1')
        version('rmc', '0.4.2')

WcfModelExpander.java (6.1 KB)

matthias-modular-brook · August 17, 2026, 1:33pm

For our project the solution was not feasible for different reasons. But I am migrating the second project now to 2026.06 and I’m running into the same issue. I am finally also adding the WcfCli gradle stuff for the model conversion.

My question is: Why do we have to go through that hassle? Wouldn’t it have been easier A12 simply imports the original models as they are and detects and executes the missing conversions?
Or it simply stores the original models and then converts them when read from the database in-memory? This would have made the migration a lot easier and would have hidden the complexity from the user.