Update iModel Creation Endpoint.

[souravbentley]

The iModel Creation Endpoint have added the following attributes:

1. iModel (create) creationMode
2. template
3. baselineFile
4. geographicCoordinateSystem

The default Create an empty instantly initialized iModel is deprecated.

With the new Endpoint changes, While Creation client must send creationMode: 'empty' in the body of request.

Changes:

1. Added props for enabling consuming app to send creationMode, template, baselineFile & geographicCoordinateSystem.
2. Added default value of creationMode to empty , allowing backward compatibility for already consuming app.
3. Added the above attributes as request body.
4. Updated Tests.

[CLAassistant]

All committers have signed the CLA.

[veekeys]

I do not understand this PR.
It just adds 4 random properties to the creation component.
I dont even see those being used anywhere.
What am I missing here?

[souravbentley]

it just adds 4 random properties to the creation component.

These properties are required by the iModel creation endpoint to send additional information along with iModel creations. Please go through the iModel Endpoint documentation.

I dont even see those being used anywhere.

These will be used in consuming application, When a consumer needs to add relevant property, he needs to send those in the component via props.

[veekeys]

I dont even see those being used anywhere.

These will be used in consuming application, When a consumer needs to add relevant property, he needs to send those in the component via props.

What?
Why this component needs props it does not use?
I dont understand. You added code which is not used here anywhere.

[veekeys]

I dont even see those being used anywhere.

These will be used in consuming application, When a consumer needs to add relevant property, he needs to send those in the component via props.

What? Why this component needs props it does not use? I dont understand. You added code which is not used here anywhere.

This component has UI to use the API.
All these props have no visual representation at all. Is this intended?

[veekeys]

it just adds 4 random properties to the creation component.

These properties are required by the iModel creation endpoint to send additional information along with iModel creations. Please go through the iModel Endpoint documentation.

These properties are not required at all. Old way of creating imodel is still supported (and will be till new major version API).
So if this PR is not planning to add UI support for baseline creation and creating from another iModel, I do not see the point of just passing these properties.

Can you share full picture what is going to happen with this component in use in your application?

[souravbentley]

The main objective of this PR is to enable the consuming side to pass additional attributes — such as creationMode, geographicCoordinateSystem, template, and baselineFile — to the iModels Creation API, allowing us to capture more detailed information during the iModel creation process.

These properties are utilized within the CreateIModel component when making the POST request to the iModel creation endpoint (refer to the POST request inside the CreateIModel component).

The UI for these inputs exists on the consuming side and is passed as children to the CreateIModel component, as shown below:

            <CreateIModel
                ...
                geographicCoordinateSystem={geographicCoordinateSystem} //Adding prop to send as body while creating iModel
            >
                <IModelLayout/>  // This is our UI
            </CreateIModel>

Here, we are simply using the CreateIModel component to accept additional props, which can then be included in the body of the request sent to the iModel Creation API (in the example above, we’re sending geographicCoordinateSystem).

---

I understand your concern that these props aren't directly used within the component itself. The challenge we're facing is that currently there's no way to include extra attributes in the request body that the CreateIModel wrapper sends.

If this approach feels confusing, we can alternatively expose a single prop— extendedRequestBody —which would allow the consuming side to pass any additional properties that should be included in the POST request.

[souravbentley]

Had a discussion with Vykintas, will raise a separate PR with extending http request body for only the required properties.