The Data Service exposes a single GraphQL mutation named geneTransactionalQuery that is used for all exposed entity modifications (Create/Update/Delete) through a transactional query. This mutation handles data conflicts.

	Note that all GraphQL APIs are also available through the Data Service REST API. For more details, refer to Section Understanding the Data Service API.

The mutation geneTransactionalQuery takes the following arguments:

GeneTransactionalQuery type is defined as follows:

export interface GeneTransactionalQuery {

    /**
     * List of elementary create operations
     */
    creates?: GeneElementaryCreateQuery[];

    /**
     * List of elementary delete operations
     */
    deletes?: GeneElementaryDeleteQuery[];

    /**
     * List of elementary update operations
     */
    updates?: GeneElementaryUpdateQuery[];
}

As you can see this interface defines the changes that we want to occur on the Data Service. The types are pretty simple key/value descriptions of the entities and fields to update:

/**
 * Describes an elementary entity delete query.
 */
export interface GeneElementaryDeleteQuery {

    /**
     * The internal id of the entity to delete
     */
    dbGeneInternalId: string;

    /**
     * JPA Entity type to delete
     */
    entityType: string;

    /**
     * The create entities field values are a list of fieldName/fieldValue.
     * Field values are serialized as String so they can go through the GraphQL
     * layer.
     *
     * In a delete query they are only used if evaluateConflicts is set on
     * the query parameters, and should only contain localValue.
     */
    fieldValues?: GeneTransactionalFieldValue[];
}

/**
 * Describes an elementary entity create query.
 */
export interface GeneElementaryCreateQuery {

    /**
     * JPA Entity type to update
     */
    entityType: string;

    /**
     * The create entities field values are a list of fieldName/fieldValue.
     * Field values are serialized as String so they can go through the GraphQL
     * layer generically.
     */
    fieldValues: GeneTransactionalFieldValue[];
}

/**
 * Describes an elementary entity update query, adds the id of existing entity
 */
export interface GeneElementaryUpdateQuery extends GeneElementaryFieldValuesQuery {


    /**
     * JPA Entity type to update
     */
    entityType: string;

    /**
     * The create entities field values are a list of fieldName/fieldValue.
     * Field values are serialized as String so they can go through the GraphQL
     * layer generically.
     */
    fieldValues: GeneTransactionalFieldValue[];

    /**
     * The internal id of the entity to update
     */
    dbGeneInternalId: string;

}

/**
 * GeneTransactionalFieldValue in transactional query represents a field with different values:
 *
 * - newValue: the value we want to set through a transactional query
 * - localValue: the locally known value for this field (only used to evaluate conflicts)
 * - remoteValue: when receiving a response from the server with a conflict, remoteValue is at this time the current value in database that is different from localValue
 */
export interface GeneTransactionalFieldValue {

    /**
     * Then entity fieldName
     */
    fieldName: string;

    /**
     * The new field value. This value is set using a transactional query
     * of type CREATE or UPDATE, and contains the requested new value for this field.
     */
    newValue?: string | null;


    /**
     * The current known field value if any. Use to detect conflicts while
     * persisting updates.
     *
     * This field is set using a transactional query of type UPDATE or DELETE.
     *
     * This local value will be compared against database value to detect conflicts. If the localValue
     * is different from database value a conflict will be returned containing both localValue (outdated)
     * and remoteValue (current database value).
     */
    localValue?: string | null;

    /**
     * Represent the current database field value.
     *
     * This field is only set by data-service when returning a conflict, and is not used in a query.
     */
    remoteValue?: string | null;
}

The GeneElementaryUpdateQuery interface describes the update of a single entity. The update can modify multiple fields of the same entity at the same time.

	Note that the updated fields are either: simple attributes, for example start or end of the Schedule entity. In this case, the value will be the new value of the field; or relation fields, for example, activity. In this case, the updated value will be the dbGeneInternalId of the referenced entity, i.e. the internal primary key.

Here is an example for GeneElementaryUpdateQuery:

{
  entityType: 'Schedule',
  dbGeneInternalId: 'dsdfsdfsd-sdfsd-fsdrfergerg-juyjdcsd',
  fieldValues: [
    {
        fieldName: 'name',
        newValue: 'Schedule1-modified'   // Update the String type field
    },
    {
        fieldName: 'activity',
        newValue: 'ddzedzesd-kpopopoopo-juyjdcsd-poi32fff'  // Update the Activity type field
    }

 ]
}

This mutation returns an instance of GeneTransactionalQueryResponse having following members:

The GeneTransactionalQueryError class describes any error that occurred during the execution of a GeneTransactionalQuery using following members:

As a developer, while working in the frontend Angular application you can modify data using Transactional Queries with the help of the GeneDataApiService.runTransactionalQuery(...) and GeneDataApiService.runTransactionalQueryWithConflicts(...) methods. Find below some examples of data modification using this API.

/**
 * Runs a transactional query without conflict evaluation. Without conflict evaluation means that:
 * Your query may overwrite data with out-of sync values.
 *
 * @param transactionalQuery gene transactional query object to execute
 * @param scenarioId gene scenario id of the item to modify
 * @param source optional component source of this query.
 *        If the source is a GeneBaseDataWidget, then it will not reload data on the DATA_UPDATED event
 *        corresponding to this query.
 * @param options the transactional query options regarding conflict detection and schema checker (default options are enabling conflict detection, and schema checker run)
 */
runTransactionalQuery(scenarioId: string, transactionalQuery: GeneTransactionalQuery, source: any = undefined, options: GeneTransactionalQueryOptions = DEFAULT_TRANSACTIONAL_QUERY_OPTIONS): Observable<GeneTransactionalQueryResponse>


/**
 * Parameters object for TransactionalQuery
 */
export type GeneTransactionalQueryOptions = {

    /**
     * When this flag is set to true the query will first evaluate conflicts before
     * persisting modification, and return conflict list if any without modifying data
     */
    evaluateConflicts: boolean;

    /**
     * Show or hide conflict editor when a conflict is detected.
     * If this flag is set to false, nothing will happen and a custom event handler
     * has to be set up to implement a custom processing of the conflict.
     *
     * If evaluateConflicts is false, this flag has no effect.
     */
    showConflictEditor: boolean;

    /**
     * Decide the logic while saving a transactional query about the Schema Checkers
     * run: NO_RUN, ASYNC_RUN (default), SYNC_RUN.
     */
    schemaCheckersRunOption: SchemaCheckersRunOption;

}

Here is an example for a Plant entity with lat and lng properties representing its location that we want to update:

import {GeneDataApiService} from "@gene/data";

// ...
function updatePlant(dataApi: GeneDataApiService, scenarioId: string, newLatitude: string, newLongitude: string) {

    dataApi.runTransactionalQuery(scenarioId, {
        updates: [{
            dbGeneInternalId: item.entity.dbGeneInternalId,
            entityType: 'Plant',
            fieldValues: [
                {
                    fieldName: 'lat',
                    newValue: newLatitude
                },
                {
                    fieldName: 'lng',
                    newValue: newLongitude
                }
            ]
        }]
        }, this).subscribe(result => {}, error => {});
}
//...

Here is an example for the deletion of a GeneIssue entity that a user clicked in the web client. This code retrieves the currently selected scenario using GeneContextService:

import {GeneDataApiService} from "@gene/data";

/**
* Deletes the issue given in parameter using currently selected scenario
*/
function deleteIssue(dataApi: GeneDataApiService, contextService: GeneContextService, issueToDelete : GeneEntity) {
    contextService.getContext()
        .pipe(
                map(c => c.scenarioIds[0]),
                map(scenarioId => dataApi.runTransactionalQuery(scenarioId,  {
                                                                                      creates : [],
                                                                                      updates : [],
                                                                                      deletes : [
                                                                                          {
                                                                                              entityType : 'GeneIssue',
                                                                                              dbGeneInternalId : issueToDelete[INTERNAL_ID_FIELD]
                                                                                          }
                                                                                      ]
                                                                                  })
                    )
    .subscribe(result => {}, error => {});
}
//...

Here is an example for the creation of new entities. This method creates the Observable that will achieve that, the caller of the method has to subscribe() to it:

    import {GeneDataApiService} from "@gene/data";

    function createQuery(dataApiService: GeneDataApiService, scenarioId: string, parameterName: string): Observable<GeneTransactionalQueryResponse> {
        const createQuery: GeneTransactionalQuery = {
            creates : [{
                entityType : 'GeneParameter',
                fieldValues : [
                    {
                        fieldName : 'name',
                        newValue : parameterName
                    },
                    {
                        fieldName : 'valueType',
                        newValue : 'n/a'
                    },
                    {
                        fieldName : 'value',
                        newValue : 'n/a',
                    },
                    {
                        fieldName : 'explanation',
                        newValue : 'n/a'
                    }
                ]
            }],
            updates : [],
            deletes : []
        };
        return dataApiService.runTransactionalQuery(scenarioId, createQuery);
    }
//...

In some cases, a custom function is needed to perform a specific operation/transformation on data (like manually calculating an average).

To do so DOC offers the possibility to implement custom methods on the Data Service extension that will be automatically exposed via GraphQL, by using specific annotations on Java classes and methods. No custom mutation can be defined at the moment.

	Note that, by default the web client is not allowing you to connect Data Grids to a custom query of an entity type. If you want to allow the user to configure Data Grids to use custom types, you need to activate this feature through the Application Preferences Menu TABLE_SHOW_CUSTOM_TYPES: false (default) or true PIVOT_SHOW_CUSTOM_TYPES: false (default) or true

The first step to create a custom GraphQL query is to create a class and annotate it with @GraphQLCustomDataService.

Every method of the bean annotated with GraphQLCustomDataSource will correspond to a GraphQL custom query.

Any annotated method first argument should be of type GeneContext, which contains context data such as scenarioId. GeneContext is filled and sent automatically via the web client components, without any specific configuration.

To add extra arguments to the custom query we can use the annotation @GraphQLCustomArgument.

For a given entity Country defined as follows:

public class Country {
    public String name;
    public int population;
}

DOC allows querying the Data Service for scenario comparison purposes. For more details, refer to Section Understanding the Data Service Scenario Comparison.

In the following example, Activity returns a list of one or more instances of the Activity and getActivityComparisonPage returns a paginated, sortable and filterable list of Activity instances

query {
    getActivityComparisonPage (
        geneContext: {
            scenarioIds: ["fbb146b1-3b7c-4564-b288-357fbee71d90"],
            referenceScenarioIds: ["01fbc776-dcc8-489d-9943-3b6785e876a2"]
        },
        geneComparisonParameters: {includeModifiedRows: DIFF,
        includeAddedRows: false,
        includeDeletedRows: false},
        dataRowsLimit: 50000,
        modifiedPageRequest: {page: 0, size: 50, sort: []}
    ){
        metrics {
            sharedRowCount
            modifiedRowCount
            addedRowCount
            deletedRowCount
        }
        modified {
            totalPages
            totalElements
            content {
                id
                plant {
                    country {
                        id
                    }
                    plantId
                 }
                durationInHours
                name
            }
        }
    }
}

The API returns the following result:

{
    "data": {
        "getActivityComparisonPage": {
            "metrics": {
                "sharedRowCount": 9000,
                "modifiedRowCount": 6009,
                "addedRowCount": 1000,
                "deletedRowCount": 1000
            },
            "modified": {
                "totalPages": 121,
                "totalElements": 6009,
                "content": [
                    {
                        "id": ["00000001", "00000001"],
                        "plant": {
                            "country": {
                                "id": ["001", "001"]
                            },
                            "plantId": ["001", "001"]
                        },
                        "durationInHours": [0.0, 2.0],
                        "name": ["Activity 0", "Activity 2"]
                    },
                    ...
                ]
            }
        }
    }
}

The "introspection" feature allows asking a GraphQL schema for information about what queries it supports. For more details, refer to the Official GraphQL Introspection documentation.

To process scenario data, both the Scenario Service and Data Service expose GraphQL APIs. GraphQL introspection queries are disabled by default for these two services, as it is recommended for a deployed application in production. For more details, refer to this link.

However, introspection queries can be useful while the application is in development. Introspection can be enabled, preferably with a Spring development profile, in the following configuration files:

by setting the following property to true:

# Enable/Disable GraphQL introspection query (default false), should be disabled in production
spring.graphql.schema.introspection.enabled: true

The Data API exposes a service that can be injected in any Angular component. For more details, refer to the Data API documentation.

It allows interacting with scenario data.

The Data API provides services and model classes to explore the Data Model Schema of your application, to run paginated or aggregation queries, but also to run custom queries exposed by DOC Data Service. The Data API is used by all DOC widgets to fetch data.

The following Sample Widget implements an example of performing a query to count current scenario issues.

    /**
     * This is a simple example of Data API usage. It performs an aggregation Query on GeneIssue type,
     * to count how many issue (rows) has the selected scenario.
     *
     * @param context current context containing the scenario selection
     *
     * @return an observable of the GeneIssue count for the current selected scenario. -1 if no scenario is selected
     */
    public countIssues(context: GeneContext): Observable<number> {
        // If no scenario returns -1
        if (context.scenarioIds.length === 0) {
            return of(-1);
        } else {

            const countIssuesQuery: AggregationQuery = {
                aggregationName : 'count_issues',
                fieldName : INTERNAL_ID_FIELD,
                aggregationKind : 'count',
                groupByFieldsNames : []
            };

            return this.dataApi.runAggregationQuery('GeneIssue', [countIssuesQuery], context)
                .pipe(
                    map(result => result.aggregations[0].buckets[0].value as number)
                );
        }
    }

The Data API also allows performing filtered queries, and provide helper methods to build filters. GeneContext objects contain definitions of your filters.

/*
 * Example of filtering by scenario
 */
const context = new GeneContextBuilder()
                        .withScenarioId('myScenarioId')
                        .build();

/*
* Example of filter on type 'Activity' having a field 'name' and 'duration'
* The following filter queries activities of the scenario
* having a name containing 'delivery' and a duration greater than '5'
*/
getFilteredContext(metaDataService: GeneMetaDataService, context: GeneContext): Observable<GeneContext> {
    return metaDataService.getTypeMetaData('Activity').pipe(
        map(activityType => {
            const activitiesFilter = new GeneEntityFilterBuilder(activityType);
            const attributesFilter = activitiesFilter
                                        .withNewClause()
                                        .withOperator('AND');

            attributesFilter.withNewAttributeFilter()
                                .withAttribute('name')
                                .withNewCriteria()
                                    .withOperator('CONTAINS')
                                    .withValues('delivery');

            attributesFilter.withNewAttributeFilter()
                                .withAttribute('duration')
                                .withNewCriteria()
                                    .withOperator('GREATER_THAN')
                                    .withValues('5');

            return  new GeneContextBuilder()
                        .withScenarioIds(context.scenarioIds)
                        .withEntityFilter(activitiesFilter)
                        .build();
        }
    ));
}

/*
* Example of filtering 'Activity' that are not scheduled. Supposing that we have two types, Activity and Schedule,
* and that Schedule references Activity through a field 'activity'.
* Note that operator INCLUDED_IN does the opposite filtering.
 */
getUnscheduledActivitiesContext(metaDataService: GeneMetaDataService, context: GeneContext): Observable<GeneContext> {
    return metaDataService.getTypeMetaData('Activity').pipe(
        map(activityType => {
                const activitiesFilter = new GeneEntityFilterBuilder(activityType);
                const attributesFilter = activitiesFilter
                    .withNewClause()
                    .withOperator('AND');

                // We want all Activities not having their internal id in scheduled activities
                //
                // This filter is equivalent to SQL Query:
                // SELECT a.* FROM ACTIVITY a WHERE dbGeneInternalId NOT IN (SELECT s.activity FROM SCHEDULE s)
                attributesFilter.withNewAttributeFilter()
                    .withAttribute('dbGeneInternalId')
                    .withNewCriteria()
                    .withOperator('EXCLUDED_FROM')
                    .withValue('Schedule#activity');

                return  new GeneContextBuilder()
                    .withScenarioIds(context.scenarioIds)
                    .withEntityFilter(activitiesFilter)
                    .build();
            }
        ));
}

The Scenario API exposes a service that can be injected in any Angular component. For more details, refer to the Scenario API documentation.

It allows interacting with scenarios.

The Sample Widget implements some examples of Scenario API usage to address basic use cases:

    /**
     * This method returns an Observable of SampleWidgetModel which is built
     * using both Scenario API and Data API.
     *
     * @param context
     */
    public loadWidgetModel(context: GeneContext): Observable<SampleWidgetModel> {
        return forkJoin([
                this.scenarioApi.getAllPathNodes(['scenario']),
                this.countIssues(context)
            ]
        ).pipe(
            map(([scenarios, issuesCount]) => this.buildWidgetModel(context, scenarios, issuesCount))
        );
    }

    /**
     * Update the Scenario object having the given scenarioUuid by setting its property SCENARIO_STATUS to the
     * given value.
     *
     * @param scenarioUuid
     * @param status
     */
    public updateScenarioStatus(context: GeneContext, status: SampleScenarioStatus): Observable<VoidResult> {
        if (context.scenarioIds.length > 0) {
            const scenarioUuid = context.scenarioIds[0];
            return this.scenarioApi.savePathProperties(scenarioUuid, {[SampleWidgetService.SCENARIO_STATUS] : status});
        } else {
            throw Error('No scenario Selected');
        }
    }

The Scenario API provides services and model classes to interact with the Scenario Service. Note that every exposed method is subject to access right checks. For example, you can list scenarios for which you have at least "READ" permission, but you won't be able to modify them if you do not have "WRITE" permission.

The Scenario API manipulates "nodes" that can represent different types of elements, such as scenarios, folders, workspaces, views and dashboards.

This allows to:

DOC allows the applications to store "events" attached to Nodes (Scenario or any other Node objects). Events have a message, an author and a timestamp. For example, each time a Scenario is locked by the system, an event is automatically created. When the user add comments through the Scenario Timeline, an event is also attached to the Scenario.

The Scenario API provides methods to:

The Task API exposes a service that can be injected in any Angular component. For more details, refer to Task API documentation.

It allows interacting with tasks and jobs. A job is a single task execution, and a task can have multiple jobs. For more details, refer to Task Events API.

The API can be used to:

Task Events are dispatched by the Framework when a Job status, progress or result changes. The application can also fire a REQUEST_RUN_NEW_JOB to request the Framework the Job Creation Wizard.

See Task Events API for more details.

The Event API exposes a service that can be injected in any Angular component. For more details, refer to the Event API documentation.

It allows listening to the different events triggered by DOC services or user interactions. The exposed Event Service is an Event bus where any event is dispatched.

DOC provides different types of events, which are extensible by extended base class GeneEvent

The following Sample Widget implements an example of Scenario Event handler that shows notifications each time a Scenario Event is received, for example, when the user selects a Scenario.

export class SampleWidgetComponent extends GeneBaseDataWidgetComponent<SampleWidgetConfiguration, SampleWidgetModel> {

    // ...

    /**
     * Overrides base method to handle Scenario Events
     */
    protected onGeneScenarioEvent(event: GeneScenarioEvent) {
        this.toastrService.info('Received Scenario Event !' + event.type);
    }

    // ...
}

The following types of event are available:

The Context API exposes a service that can be injected in any Angular component. For more details, refer to Context API documentation.

It allows storing the application state in a serializable object. It contains:

This context is sent as a parameter of the Data Service requests when you are opening a View or a Dashboard. Each time the user modifies the context by modifying Scenario/Entities selection, or changing filters, the context is updated, saved through the Scenario Service, and all widgets are notified about the Context update.

As stated above DOC provides a notion of selected entities that are propagated to the web client elements that support this feature. There are currently three modes supported in DOC :

A widget can take part in this behavior by implementing GeneWidgetSelectionAware interface in a way similar to this for instance

export class SampleWidgetComponent implements GeneWidgetSelectionAware {

    // ...


    /**
     * Return among the context selections, the supported selection(s).
     * Returns an empty array if current selection is not supported (has no impact on data) on
     * the current widget state.
     *
     * @param context current context containing a selection
     */
    getSupportedSelection(context: GeneContext): GeneContextSelection {
        // simple utility method filtering entities by the given type
        return GeneSelectionUtils.getSubSelection(context.selection, this._widgetConfiguration.dataType);
    }

    /**
     * declare which selection mode this widget supports
     */
    getSupportedSelectionModes(): SelectionMode[] {
            return ['select', 'filter', 'highlight'];
    }
    /**
     * Get the current selection mode of the widget
     */
    getSelectionMode(): SelectionMode {
            return  this.selectionMode;
    }


    /**
     * Set the current selection mode of the widget
     * @param mode
     */
    setSelectionMode(mode: SelectionMode) {
        // store the selection mode and take it in account when loading data
        this.selectionMode = mode;
        // request reload of widget data
        this.requestLoadData();
    }
    // ...
}

It is important to understand that the selected entities provided by the context API are based on what we call Business Keys, it is a combination of all the properties that allow to describe a Business Entity instance in a unique way. This is implementation is chosen among other reasons, to allow to compare same entities across different scenarios, without relying on unique generated identifiers.

When you manipulate entities obtained by the Data API, those objects do not contain business key metadata by default.

For this reason if you want to compare data in a custom component against entities provided by Context API you have to enhance them using the MetaData API, see this example of GeneBaseDataWidget.loadData() implementation which takes into account the current selectionMode and populates all the entities with relevant business key information to be used for Context Selection support.

import { INTERNAL_BK_TOKEN_FIELD } from '@gene/data';


    loadData(context: GeneContext): Observable<MyCustomType[]> {


        const metaModel$ = this.metaDataService.getMetaModel();
        const dataObjects$ = this.dataApiService.runQuery<T[]>(context, this._widgetConfiguration.entityTypeName);


        return forkJoin([dataOjects$, metaModel$]).pipe(
                flatMap(([dataOjects, metaModel]) => {
                    const typeMetaData = metaModel.getTypeMetaData(this._widgetConfiguration.entityTypeName);
                        .pipe(
                            // Important! we need to "enrich" other events with business key information in order to support filtering and highlighting
                            tap((dataOjects: T[]) => dataOjects.forEach(e => metaModel.enrichEntityWithBusinessKeyInformations(e, type, (o) => this.colorService.getHexColorForObject(o)))),
                        );
                })
            );
    }



// ...
    refreshSelection() {
        if (this.selectionMode === 'highlight' || this.selectionMode === 'select') {
                this.contextService.context.pipe(first()).subscribe(c => {
                    const currentType = this._widgetConfiguration.dataType;
                    const selection = GeneSelectionUtils.getSubSelection(c.selection, currentType);

                    // grid options.api is the api to interact with ag-grid tables
                    this.gridOptions.api.forEachNode(node => {
                            // here is the important part: retrieve the business key token from the entities displayed in the widget
                            const nodeBKinfo = node.data[INTERNAL_BK_TOKEN_FIELD];
                            // compare the business key to all the entities in current context selection
                            const selected = selection.selectedEntities[currentType].indexOf(nodeBKinfo) >= 0;
                            // select the node accordingly
                            node.setSelected(selected);
                        });

                }
            );
        }
    }


    setSelectionMode(mode: SelectionMode) {
        // store the selection mode and take it in account when loading data
        this.selectionMode = mode;
        // request reload of widget data
        this.refreshSelection();
    }

// ...

The Meta Data API exposes a service that can be injected in any Angular component. For more details, refer to Meta Data API documentation.

It allows getting metamodel information of your data-model types, as defined through the JDL file.

    constructor(protected metaDataApi: GeneMetaDataService) {

        // Example of fetching information for type 'Activity'

        metaDataApi.getTypeMetaData('Activity').subscribe(entityType => {
            console.log('business key fields', entityType.getBusinessKeyFields()) ;
            console.log('Available queries', entityType.getQueries());
            console.log('Relation fields', entityType.getRelations());
            console.log('All fields', entityType.getFields());
        });

    }

The Action API exposes a service that can be injected in any Angular component. For more details, refer to Action API documentation.

It allows configuring and performing UI-related actions from the web client. These actions can be associated with:

When creating a new project, several action samples are provided in web/src/app/modules/sample-actions:

Actions have an ID, a name and a description. The name and the description can be translated through the i18nName and i18nDescription keys, respectively.

An action is defined by several parts:

The following sample executes an action that copies the URL of the current page.

import { GeneAction, GeneActionExecutor, GeneActionManifest } from "@gene/widget-core";
import { GeneClipboardUtils } from "@gene/widget-data";
import { of } from "rxjs";

/**
 * A sample action that copies the current URL to the clipboard
 */
export const SAMPLE_ACTION_COPY_URL: GeneActionManifest = {
    id: "sample-copy-url",
    name: "Sample Action — copy current URL",
    icon: 'copy'
};

/**
 * Executor function for SAMPLE_ACTION_COPY_URL action. Copy the current URL to the clipboard.
 */
export const copyUrlExecutor = ((_: GeneAction<string>) => {
    const success = GeneClipboardUtils.copyUrlToClipboard();
    return of( { success });
}) as GeneActionExecutor;

An action requires to be registered by code in order to be available in the web client at runtime. To do so, the GeneActionService#registerAction(...) must be used.

Here are some examples of action registrations that are available in the code samples of the web-frontend module.

Finally, actions can also be executed programmatically using GeneActionService to provide additional data to an action, which can be combined with a parameter resolver function, as in sample-action-hello-world-with-data.ts.

// Executing the action with runtime data to be used by the parameter resolver
actionService.executeAction({manifest:SAMPLE_ACTION_HELLO_WORLD}, `Jane Doe, born on ${new Date().toLocaleDateString()}`);

If need be, the Action API can display a configurator via the method getActionConfigurator.