Idea Summary
Both Form and Interactive Grid regions have Automatic Row Processing process type which could optionally be coded in PL/SQL. Having an option to declaratively use APIs will make it lower code.

This is similar to FR-3049.

Use Case
Sometime Form and IG regions are based on complex views which can't be manipulated by insert/update/delete statements and APEX has a formidable option to manage this through PL/SQL Target Type and APEX$ROW_STATUS variable.

Incapsulating the complex logic in the database (CRUD API) is recommended, especially if it's reused in different places. But still we have to invoke the API from PL/SQL.

Leveraging the Invoke API declarative APEX functionality would bring all the advantages we've seen in 22.2 (parameter mapping, data type aware, synchronization, etc.) with less code.

Preferred Solution (Optional)
As-Is

The Form region has an Automatic Row Processing process target type set to PL/SQL (Pn_ENTITY_ID is the primary key page item of the form - similar process for Interactive Grid where “Pn_” is omitted):

:Pn_ENTITY_ID:= Utility_Pkg.CRUD_Entity(P_APEX_Row_Status => :APEX$ROW_STATUS
                                       ,P_Field1          => :Pn_FIELD1
                                       ,P_Field2          => :Pn_FIELD2
                                       ...
                                       );

To-Be

The Form or an Interactive Grid region has an Automatic Row Processing process target type set to Invoke API:

• Package: Utility_Pkg
• Procedure or function: CRUD_Entity
• Parameters:
  • Function Result: Pn_ENTITY_ID
  • P_APEX_Row_Status: APEX$ROW_STATUS
  • P_Field1: Pn_FIELD1
  • …