Update BIE root view to include Open API options

[dubnemo]

Currently I have been using Remark to capture Open API information since it display nice on the BIE list view.

Perhaps this is the appropriate UI to capture the following, as there seems to be enough real estate on the screen, and these parameters are directly related 1:1 to the BIE:

• Resource Path
• Verb
• Operation Id
• requestBody | responseBody
• Array
• Suppress Root element

Replace Remark with real OpenAPI fields

Here is how I historically have used Remark to have a logical list of related BIEs. The new issue #1492 is similar type of view:

[dubnemo]

@bingqi2045 @hakjuoh I think this is the way to go. Define these parameters on the BIE root itself, and which would help the merge into the single yml

[bingqi2045]

@dubnemo @hakjuoh

In this example, two different verbs are assigned to the same BIE, so it is not possible to directly related 1:1 to BIE.

[hakjuoh]

@bingqi2045 The OpenAPI information will appear if the BIE has a relationship with the OpenAPI document as below.

[dubnemo]

@hakjuoh @bingqi2045 yes, that is exactly what I was envisioning. Maybe between the context definition and component definition.

Are these editable? If you choose Response Body, is it stored the corresponding table for response? Or are the tables (response, request, parameters) now collapsed into one table?

You asked in #1492 if there was a chance if the BIE could be reused across multiple operations, which in this case this information could repeat. Would that be possible? It would be scrollable. These are the scenarios, specifically when the identifiers for the core and child objects are available after creating in the DB after POST:

VERB	Part	Comment
POST	responseBody	After generation of ids in a DB, the complete object is returned back. This responseBody is a copy of the requestBody with the appropriate generated Ids enabled.
GET	responseBody	Returns the current object with identifiers, as persisted in the DB.
PATCH	responseBody	After update of the object, the current object with identifers is returned.
PATCH	requestBody	Seldom used, but if so, this is a user-defined component that assembles BCCPs that can be updated. If there are only a few these are most often query parameters.
PUT	requestBody	Provides the ability to replace the complete business object. These is seldom used today, so lower priority.
PUT	responseBody	After replacement of the object, the current object with identifers is returned.

Each reused BIE would be a row in the request, response or parameter table, a UNION of these core attributes would be displayed:

• Resource Path
• Verb
• Operation Id
• Array
• Suppress Root element

[dubnemo]

Note the relationship to a single OpenAPI doc, and the ability to add a BIE relationship to the doc.

We should also review the logic to generated the OperationId. I am showing the reference type, and the verb mapping we did for securitySchema reference with create, etc. prefixed to the BIE name.

<operation_id>::= <referenceType>_<crudVerb><BIEName>
<referenceType> ::= 'response' | 'requestBody' | 'parameters'

[bingqi2045]

@dubnemo @hakjuoh Regarding the question: Are these editable? If you choose Response Body, is it stored the corresponding table for response? Or are the tables (response, request, parameters) now collapsed into one table?

Yes, They are editable. the response, request and parameters tables are separate and stored in the corresponding table in the database.