Configuring additional features and settings for Operations

Configure additional features for Operations to customize the settings.

Using transactions in sequence

Use transactions in sequence when one API transaction must first retrieve a value that another transaction needs as input. The transactions must be in the same data service. Use the transaction name and field ID to reference the output from the earlier transaction in the input value of the later transaction, for example, {SearchCOHead.ORNO}.

Sequenced transactions are useful when the component should display or process data that cannot be retrieved in a single API call. For example, one transaction can retrieve an order number, and the next transaction can use that order number to retrieve additional order details.

  1. Create or open a data service.
  2. Add the first transaction and configure the input and output of the transaction.
  3. Add the next transaction in the same data service.
  4. On the Input tab for the second transaction, specify the output from the first transaction in the Value column using {TransactionName.FieldID}
  5. Click Save on the transaction, data service, and application.
  6. Connect the data service to the component operation and add the required interaction.
    Note: If you add several transactions to a data service, save the data service configuration before you rely on the output from an earlier transaction.

Using Exclude transaction data from output

Use the Exclude transaction data from output option when a transaction is needed only as an intermediate step in a sequence and does not contribute fields or rows to the component output. This option is especially useful in data grids, where intermediate transactions can otherwise create empty or confusing rows.

For example, a first transaction can retrieve a header value that is needed by a second transaction that lists lines. If only the line data should be displayed in the data grid, exclude the header transaction from the output while still using its values as input to the line transaction.

  1. Open the data service configuration.
  2. Edit the transaction used only as an intermediate step.
  3. On the Properties tab, select the Exclude transaction data from output check box.
  4. Click Save on the transaction and the data service.
  5. Open the component configuration and add output fields only from the transaction to display.
  6. Click Saveon the component and the application.

Renaming conflicting output IDs

If a data service contains multiple transactions, more than one transaction can return fields with the same ID. When fields have the same ID, the component might not use the correct field. Rename one or more output IDs so that each field that the component must display or use has a unique ID.

Use unique output IDs when two transactions return the same field, such as registration date, status, or description, but the values come from different contexts and the component must access both values.

  1. Open the data service configuration
  2. Edit the transaction that contains the output field you need to rename.
  3. Navigate to the Output tab.
  4. Update the value in the ID column for one of the duplicate fields.
  5. Use an ID that is descriptive and at least four characters long.
  6. Click Save on the transaction, data service, and application.
  7. Return to the component and add or update the fields that use the renamed output ID.

    For example, if two transactions both return RGDT, rename one RGDT field to a name such as RGDTItemBasic so both registration date fields can be displayed correctly.

Specifying File on output fields

Some field IDs exist in several M3 tables and might have different value maps or meanings depending on the table. Use the File column in the data service output to specify which table to use to interpret the field value.

Specifying the File value is useful for fields such as status (STAT). The same field ID might exist in several tables but represent different statuses. Without a value in the File column, the component might display incorrect lookup values or descriptions.

  1. Open the data service configuration
  2. Edit the relevant transaction.
  3. Navigate to the Output tab.
  4. Find the output field that needs table-specific interpretation.
  5. Specify the table name in the File column, for example, OCUSMA for customer-related values.
  6. Click Save on the transaction, data service, and application.
  7. Verify the field in the component, especially if it uses lookup or value map display.

Using multiselect configuration

Multiselect configuration lets a data service transaction run for several selected rows in a data grid. Use multiselect configuration when the same action should be applied to multiple records, such as updating selected order lines or running a transaction for several selected items.

The data grid must allow multiple row selection, and the data service transaction must be configured to use the selected rows as repeated input.

  1. Open the data service configuration
  2. On the Rows tab, enable Multiple row selection.
  3. Add a toolbar button that users select to run the action.
  4. Create or open the data service that contains the transaction to run for the selected rows.
  5. On the transaction Properties tab, open Multiselect configuration and select the relevant data grid as the component.
  6. Configure the transaction input to retrieve values from the selected rows or from a dialog, as needed.
  7. Connect the data service to an operation in the data grid.
  8. Add an interaction so that selecting the toolbar button runs the operation.
  9. Click Save on the data service, component, and application.

Using Exclude fields with empty values

Use Exclude fields with empty values when empty fields should not be sent to the API transaction. This is important for transactions where empty values are interpreted as actual input and can overwrite, clear, or otherwise affect existing data.

The setting is available for Add and Update transactions. When enabled, empty fields are excluded from the payload sent by the transaction.

  1. Open the data service configuration.
  2. Edit the relevant transaction.
  3. On the Input tab, locate Exclude fields with empty values which is displayed below the data grid.
  4. Select the check box to prevent empty fields from being sent to the API.
  5. Click Save on the transaction, data service, and application.
  6. Test the transaction with both populated and empty fields to confirm that only the intended values are sent.

Keeping or clearing fields when changing data service

When you change the data service for an operation and the component already has configured fields or columns, a dialog is displayed so you can choose whether to keep the existing field setup, clear the field setup, or cancel the change.

Keeping fields is useful when the new data service is similar to the old data service and you want to preserve field layout, formatting, and related configuration instead of adding those settings again manually. When you keep fields, the system automatically connects matching field names in the new data service.

  1. Change the data service for an operation in a component with configured fields or columns.
  2. In the dialog box, select one of these options:
    Cancel
    The data service does not change, and the existing fields remain the same.
    Change and Keep fields
    The data service changes, and the configured fields remain configured.
    Change and Clear fields
    The data service changes, and the configured fields from the previous data service are removed.
  3. If you keep fields, review the field configuration after the change. Matching fields are connected automatically when the new data service has a field with the same name. Fields that are not available in the new data service remain in the list but are highlighted in red.
  4. Remove any unwanted unavailable fields manually, then save the component and application.
    Note: 
    • Custom fields are not affected by the keep or clear choice and are always kept.
    • Unavailable fields do not prevent saving, but the component does not use them. The component displays only fields that are available in the new data service.

    • When you change from an MI data service to a LISTMI data service and select Change and Keep fields, existing fields are not reconnected automatically. LISTMI fields use a different naming convention. For example, SUNO becomes XXSUNO.

      Unmatched fields remain in the list and are highlighted in red. You can reconnect each highlighted field to its LISTMI equivalent, or remove the fields that no longer apply.

Effects of keeping or clearing fields on related configuration

When you keep fields, the application preserves settings that use component fields when possible. Review these settings after you change the data service:
  • Conditional styling: If you keep fields, conditional styling remains valid for fields that exist in the new data service and have the same name. The system marks fields that are not in the new data service as invalid. You can update those fields to use a new field or remove them.
  • Group headers and separators: When you choose Keep fields, the system keeps group headers and separators in Form components. When you choose Clear fields, the system removes them.
  • Variables and local variables: Variables that reference a component field, including local variables in link configuration, remain valid if the field exists in the new data service.
  • Filter, Select, and Search: Filter, Select, and Search configurations remain valid if the referenced field exists in the new data service and the new data service uses the same transaction type as the previous one, for example List to another List or Search to another Search. Switching between different types, such as List to Search, is not supported. The system clears the fields, and you must add them again.