JavaScript Extension Development API for Oracle Visual Builder Cloud Service - Classic Applications: Class: operation/js/api/Operation

An API object representing a single data operation.

This object is useful for both roles, ABCS Business User and ABCS Developer.

ABCS Developer needs to produce Operation instances to make his custom custom Business Object Provider (BOP) useful.
ABCS Business User consumes these Operation instances and performs the operation using Operation.perform(..) method.

Version:

17.1.1

Source:

operation/js/api/Operation.js, line 54

See:

Operations to understand how to get certain registered operation and perform it.
Operations.read(..)
Operations.create(..)
Operations.update(..)
Operations.delete(..)

Returns:

Type: Operation

Members

(static) SpecialType :String

stable API

Represents a special kind of an Operation.

Special type is relevant only in cases of Operation instance with standard type set to Operation.Type.READ_MANY or Operation.Type.READ_ONE. For all other Operation.Types, the value is ignored and resulted behavior is not guaranteed by ABCS.

Type:

String

Properties:

Name Type Description

Name	Type	Description
`QUERY_BY_ID`	String	Marks an Operation capable to retrieve single record by ID. Having an Operation instance marked with this special type has strong impact on the resulted capabilities of the Entity which supports such operation: If an Entity provides Operation of type QUERY_BY_ID, it allows ABCS UI to make Edit/Detail pages available for that Entity. This is because ABCS needs to be able to fetch only particular record when you click on Edit/Detail action in the table itself. Also Edit/Detail pages of that Entity will become automatically bookmarkable. This is caused by the fact that later ABCS needs to be able to retrieve opened record from bookmarked URL. Since the URL contains ID of the record, ABCS reads the record automatically by using the Operation marked with special type QUERY_BY_ID. Please be aware, that only one Operation of type QUERY_BY_ID is expected for each Entity. If your BOP provides more Operations of this type, the behavior is not guaranteed by ABCS.
`QUERY_BY_IDS`	String	Marks an Operation capable to retrieve many records using the given list of IDs. Includes a capability for ABCS to fetch many records given their IDs. Such Operation is used when Entity which provides this Operation is being referenced from other Entity. If there is a table of referencing Entity and the table has visible column which correspond to the referenced Entity, operation of type QUERY_BY_IDS will be used to fetch all referenced values needed for the table view. And it will be done effectively in one call. To illustrate on an example: ABCS application consists of two Entities: Employee and Department Department contains few Properties: Id (KEY), Name (TEXT) Name could be string like 'Sales', 'Department' etc. Employee contains few Properties: Id (KEY), Firstname (TEXT), Lastname (TEXT), Age (NUMBER) Each Employee also has it's Department assigned: refToEmployee (REFERENCE) Now assume that ABCS client want to have an Employee table on the Home page and the table is configured to show Firstname, Lastname and Department-Name columns. If client opens Home page, we need to fetch all Employees and for each record fetch assigned Department to be able show Department name instead of just ID. To make this effective, ABCS looks for Operation of type QUERY_BY_IDS and use that one if available. If it's not provided by the referred Entity (Department in this case), ABCS attempts to do the same using Operation of type QUERY_BY_ID which is obviously much less effective as one call needs to be done per each visible row. Please be aware, that only one Operation of type QUERY_BY_IDS is expected for each Entity. If your BOP provides more Operations of this type, the behavior is not guaranteed by ABCS.
`QUERY_BY_ANYTHING`	String	Marks an Operation capable of handling any kind of input Condition. Having an Operation of this special type available gives ABCS an opportunity to query any kind of data. This is used for ABCS UIs like "Advanced Search" or "Default Query" which, thanks to having this Operation available, can give ABCS user much more flexibility on how to visually build the query. Please be aware that by registering the Operation of this type, you're obligating that the operation function will handle all possible combinations of AND/OR RelationOperators between unlimited number of parameters. If that's not true, ABCS UI might allow final client to setup query which is actually unsupported by your BOP. To illustrate on an example: Assume ABCS application contains Employee Entity. Employee contains few Properties: Id (KEY), Firstname (TEXT), Lastname (TEXT), Age (NUMBER) Employee also provides an Operation of type QUERY_BY_ANYTHING. Now assume that ABCS client wants to have an Employee table on the Home page and opens "Default Query" editor. Since Operation of type QUERY_BY_ANYTHING is available, ABCS allows client to Add/Remove any number of query rows. It also allows client to set any Operators which is by default supported by ABCS. Because the client is capable to make very various configurations and because he always expects from ABCS that his application is going to work, the underlying function making the real call has to be capable to manage all these possible configurations. Otherwise client app will became broken. Please be aware, that only one Operation of type QUERY_BY_ANYTHING is expected for each Entity. If your BOP provides more Operations of this type, the behavior is not guaranteed by ABCS.

QUERY_BY_ID

String

Marks an Operation capable to retrieve single record by ID.

Having an Operation instance marked with this special type has strong impact on the resulted capabilities of the Entity which supports such operation:

If an Entity provides Operation of type QUERY_BY_ID, it allows ABCS UI to make Edit/Detail pages available for that Entity. This is because ABCS needs to be able to fetch only particular record when you click on Edit/Detail action in the table itself.
Also Edit/Detail pages of that Entity will become automatically bookmarkable. This is caused by the fact that later ABCS needs to be able to retrieve opened record from bookmarked URL. Since the URL contains ID of the record, ABCS reads the record automatically by using the Operation marked with special type QUERY_BY_ID.

Please be aware, that only one Operation of type QUERY_BY_ID is expected for each Entity. If your BOP provides more Operations of this type, the behavior is not guaranteed by ABCS.

QUERY_BY_IDS

String

Marks an Operation capable to retrieve many records using the given list of IDs.

Includes a capability for ABCS to fetch many records given their IDs. Such Operation is used when Entity which provides this Operation is being referenced from other Entity. If there is a table of referencing Entity and the table has visible column which correspond to the referenced Entity, operation of type QUERY_BY_IDS will be used to fetch all referenced values needed for the table view. And it will be done effectively in one call.

To illustrate on an example:

ABCS application consists of two Entities: Employee and Department
Department contains few Properties: Id (KEY), Name (TEXT)
Name could be string like 'Sales', 'Department' etc.
Employee contains few Properties: Id (KEY), Firstname (TEXT), Lastname (TEXT), Age (NUMBER)
Each Employee also has it's Department assigned: refToEmployee (REFERENCE)

Now assume that ABCS client want to have an Employee table on the Home page and the table is configured to show Firstname, Lastname and Department-Name columns. If client opens Home page, we need to fetch all Employees and for each record fetch assigned Department to be able show Department name instead of just ID. To make this effective, ABCS looks for Operation of type QUERY_BY_IDS and use that one if available. If it's not provided by the referred Entity (Department in this case), ABCS attempts to do the same using Operation of type QUERY_BY_ID which is obviously much less effective as one call needs to be done per each visible row.

Please be aware, that only one Operation of type QUERY_BY_IDS is expected for each Entity. If your BOP provides more Operations of this type, the behavior is not guaranteed by ABCS.

QUERY_BY_ANYTHING

String

Marks an Operation capable of handling any kind of input Condition.

Having an Operation of this special type available gives ABCS an opportunity to query any kind of data. This is used for ABCS UIs like "Advanced Search" or "Default Query" which, thanks to having this Operation available, can give ABCS user much more flexibility on how to visually build the query.

Please be aware that by registering the Operation of this type, you're obligating that the operation function will handle all possible combinations of AND/OR RelationOperators between unlimited number of parameters. If that's not true, ABCS UI might allow final client to setup query which is actually unsupported by your BOP.

To illustrate on an example:

Assume ABCS application contains Employee Entity.
Employee contains few Properties: Id (KEY), Firstname (TEXT), Lastname (TEXT), Age (NUMBER)
Employee also provides an Operation of type QUERY_BY_ANYTHING.

Now assume that ABCS client wants to have an Employee table on the Home page and opens "Default Query" editor. Since Operation of type QUERY_BY_ANYTHING is available, ABCS allows client to Add/Remove any number of query rows. It also allows client to set any Operators which is by default supported by ABCS. Because the client is capable to make very various configurations and because he always expects from ABCS that his application is going to work, the underlying function making the real call has to be capable to manage all these possible configurations. Otherwise client app will became broken.

Please be aware, that only one Operation of type QUERY_BY_ANYTHING is expected for each Entity. If your BOP provides more Operations of this type, the behavior is not guaranteed by ABCS.

Version:

17.1.1

Source:

operation/js/api/Operation.js, line 572

See:

Entity

(static) Type :String

stable API

Represents behavior classification of single Operation instance.

Type of the Operation is the most important information that Abcs needs to understand in order to see the logical purpose of the operation itself. The information is used to make the action accessible on appropriate places within Abcs UI.

If your operation is expected to be available for retrieving collection data, it needs to have Operation.Type.READ_MANY set. That makes it available for example when client drops the Table into an empty page.
If you would also like to have Create page available for such table, you need to provide operation with Operation.Type.CREATE type which gives Abcs an understanding of what to perform when "Create" button is being clicked.
If you would also like to have Delete action available for each Collection record, you need to provide operation with Operation.Type.DELETE type which gives Abcs an understanding of what to perform when "Delete" item is being clicked.
If you would like to have also Edit/Detail pages available for the selected Collection record, you will need to implement operation with Operation.Type.READ_ONE type and with special type set to QUERY_BY_ID which gives Abcs a possibility to read whole record. It also allows the infrastructure to restore bookmarked Edit/Detail page.
To make Edit page working correctly, you also need to provide operation with Operation.Type.UPDATE type which gives Abcs an understanding of what to perform when either Edit or Detail button is being clicked.
If you would also like to provide an Action-like operation which performs certain business rule (e.g. Fire an employee, Raise Salary etc.), Operation.Type.PERFORM should be used. Although, please be aware that these are unsupported by ABCS UI at the moment and because of that, no functionality is guaranteed by ABCS itself.

Type:

String

Properties:

Name	Type	Description
`READ_ONE`	String	Operation that reads a single record.
`READ_MANY`	String	Operation that reads multiple records.
`CREATE`	String	Operation that creates a single record.
`UPDATE`	String	Operation that updates a single record.
`DELETE`	String	Operation that deletes a single record.
`PERFORM`	String	Operation that performs non-CRUD action.

Version:

17.1.1

Source:

operation/js/api/Operation.js, line 529

Methods

perform() → {Promise.<operation/js/api/OperationResult>}

stable API

Performs this operation.

Each Operation.perform(..) method call returns an instance of OperationResult. It either:

Provides returned data in case Operation perform correctly.
It also can contain any other metadata which Business Object Provider decides to return. For example PaginationCursor can be available if the perfomed Operation has type Operation.Type.READ_MANY set and provider implemented capability to paginate through the resulted records.
Provides error code, message and possibly any other additional error information in case Operation performed incorrectly.

To check the result of Operation.perform(..) call, you can use:

OperationResult.isSuccess() to check if the call was performed correctly and resulted in a OperationResult.Success.
OperationResult.isFailure() to check if the call was performed incorrectly and resulted in an OperationResult.Failure.

Version:

15.4.5

Source:

operation/js/api/Operation.js, line 174

See:

Returns:

Promise of the OperationResult for this operation.

Type: Promise.<operation/js/api/OperationResult>