mORMot Open Source

Luwo

Member

Registered: 2025-08-08

Posts: 4

TOpenApiParser fails on this OpenApi-Schema...

Bonjour Dear Arnaud, dear Community

I try to generate Rest-Classes out of this OpenApi-Json-Schema ("1.1-OnPrem"): OpenAPI description v1.1

1) fetched the OpenApi-Definition

mget https://developer.jtl-software.com/_spec/products/erpapi/@1.1-onprem/openapi.json?download  /o openapi_v1.1.json

2) This is the Code

  ApiParser := TOpenApiParser.Create('JTL');
  try

    ApiParser.Options := [];
    ApiParser.ParseFile('openapi_v1.1.json');
    ApiParser.ExportToDirectory( 'c:\temp' );

  except  
    on E : Exception do writeln('Exception: '+E.Message);
  end;

...but it failes with this exception

 TOpenApiParser.ParseRecordDefinition: JTL.Data.Contracts.Keys.ArtikelKey is integer, not object 

what I already did:

• Validated this schema and it seems to be correct

• The former schema ("1.0-OnPrem") runs fine  - OpenAPI description v1.0 (maybe of less references? idk)

I could not figure out what the problem causes. Could sombody help here?

Many Thanks in advance
Greetings Luwo

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,123

Website

Re: TOpenApiParser fails on this OpenApi-Schema...

So we first have an integer:

      "JTL.Data.Contracts.Keys.ArtikelKey": {
        "type": "integer",
        "additionalProperties": false,
        "format": "int32"
      },

which is then referenced as an object:

      "JTL.Shared.Patterns.Maybe.MayOfJTL.Data.Contracts.Keys.ArtikelKey": {
        "type": "object",
        "allOf": [
          {
            "$ref": "#/components/schemas/JTL.Data.Contracts.Keys.ArtikelKey"
          }
        ],
        "additionalProperties": false
      },

Then as an array:

      "JTL.Shared.Patterns.Maybe.MayOfSystem.Collections.Generic.ListOfJTL.Data.Contracts.Keys.ArtikelKey": {
        "type": "array",
        "items": {
          "type": "array",
          "items": {
            "$ref": "#/components/schemas/JTL.Data.Contracts.Keys.ArtikelKey"
          }
        },
        "additionalProperties": false
      },

I understand the concept to map an integer as an array (i.e. mapped into an array of integer) - but I don't know how to change an integer as an object...
Or perhaps just use the original integer type (since in DotNet an integer is also an object)?

The worse is that those "JTL.Shared.Patterns.Maybe.*" types are in fact NOT used anywhere in the schema.
The framework generating this OpenAPI specs sounds a bit overlooking its output.

Have you any idea?
I don't know what to do with this.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,123

Website

Re: TOpenApiParser fails on this OpenApi-Schema...

So I will just replace this definition with a "variant" type in our code: which may be whatever is needed from JSON (integer/array/object/string...).
https://github.com/synopse/mORMot2/commit/e226f4417
Since the "JTL.Shared.Patterns.Maybe.*" types are not used, it won't hurt.
From my side, it did the trick, and the units are generated and do compile.

I have added this OpenAPI specs to the reference set run during regression tests:
https://github.com/synopse/mORMot2/commit/0a60cd101

Luwo

Member

Registered: 2025-08-08

Posts: 4

Re: TOpenApiParser fails on this OpenApi-Schema...

Salut Arnaud!

Tu es mon héros officiel du jour! :-)
you are my officially "hero of the day"! :-)

great! generation runs
-------------------

If you don´t mind, I have another issue with this schema:

IDK why, but the "securityScheme" seems to appear nowhere

    "securitySchemes": {
      "Wawi": {
        "type": "apiKey",
        "description": "Fill Wawi Token here",
        "name": "Authorization",
        "in": "header"
      }

It is just a header-field "Authorization" with the value "Wawi <guid-string>" as described in the schema-comment at the beginning.

Would it be a good Idea to define a kind of "default-header" in the Client-Class?
i.e. in case of

• the needed header isn´t specified that way that the generator could find it

• the format of the value itself seems to be a bit "uncommon" (string + GUID)

• to simplify the calls (I don´t have to add this header in each function, though it is needed in every function and is always the same)

Maybe something like this:

procedure TForm1.CreateApiClient;
begin
 FJsonClient := TJsonClient.Create(FBaseUrl); 
 FClient := TJtlClient.Create(FJsonClient) ;
 
 // also because of the format of the value, what is "Wawi " + GUID-String 
 FClient.AddDefaultHeader('Authorization', 'Wawi '+GetApiKey);
end;

What do you think?

greetings

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 15,123

Website

Re: TOpenApiParser fails on this OpenApi-Schema...

AFAICT you already have IJsonClient.SetBearer() for this purpose.

Luwo

Member

Registered: 2025-08-08

Posts: 4

Re: TOpenApiParser fails on this OpenApi-Schema...

Yes Arnaud, you're absolutely right.

That's the standard that 99.99% of API developers probably adhere to

Unfortunately, in this case, the bearer isn't called "Bearer" but "Wawi"

In other words, this code here (from "mormot.net.client.pas")

    case Scheme of
      wraBasic:
       ...
      wraBearer:
        SockSendLine(['Authorization: Bearer ', Token]);

It should look like this, but that's nonsense.

    case Scheme of
      wraBasic:
       ...
      wraBearer:
        SockSendLine(['Authorization: Wawi ', Token]);

I have no idea why the name was chosen that way. But I'm sure there's a reason for it...   ...but I just don't know it :-)

greetings

danielkuettner

Member

From: Germany

Registered: 2014-08-06

Posts: 395

Re: TOpenApiParser fails on this OpenApi-Schema...

I have no idea why the name was chosen that way. But I'm sure there's a reason for it...   ...but I just don't know it :-)

Wawi is a short for Warenwirtschaft.
JTL-Software-GmbH are Germans. For such Wawi is a fundamental word in their business language (just like beer for English -> beer -> bearer)

Luwo

Member

Registered: 2025-08-08

Posts: 4

Re: TOpenApiParser fails on this OpenApi-Schema...

Hallo Daniel

deutsch
Danke für deinen Hinweis. Und ja, natürlich hast Du Recht. Mir ist schon klar, dass "Wawi" für "Warenwirtschaft" steht. (Und jetzt auch nochmal für alle Nicht-German-Native-Mitleser erklärt )
Mir ging es um einen anderen Punkt, WARUM sollte man einen Quasi-Standard derart verbiegen. Wo ist da der Sinn? Wird vielleicht später eine weitere Securtiy-Schicht drübergestülpt? IDK.
Ich werde das mal direkt beim Hersteller in Erfahrung bringen und dann hier auch was dazu schreiben.

english
Thanks for your comment. And yes, of course you're right. I'm well aware that "Wawi" stands for "warehouse management." (And now also explained for all non-German readers )
I was talking about a different point: WHY would you bend a quasi-standard like that? What's the point? Will another security layer be added later? IDK.
I'll find out directly from the manufacturer and then write something about it here.

PS: "beer" -> "bearer" - you made my day