Plug-In Component

A Property ID is the unique field ID used by Unqork to track and link components in your module.

The Property ID is how the software identifies your component. Using Property IDs lets you link components, creating logic-based configurations and API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. calls.

Property IDs must use camel case A naming convention for computer programming. Use camelCase for Property IDs, for example: newUser, lastName, & rdoButton. (stylized as camelCase) without spaces or punctuation.

Assign components one-word labels to help organize, identify, and group the components in your application.

Consider an example from the API Specification Snippet: Field Tags are applied to Hidden components in the panelRequest and panelResponse Panels. The Field Tags identify the data type of parameters included in the API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. request and response. The API Docs Dashboard tool populates with information about each parameter’s data type, identified by the Field Tag.

Field Tags act as a type of Property ID A Property ID is the unique field ID used by Unqork to track and link components in your module. group and let you group components for configuration purposes. Field Tags let you target two or more components using a simple logic component.

For example, add the Field Tag tagForDecision to multiple components in your module. Open the Inputs table of a Decisions component and reference the tagForDecision Field Tag as the input of the Decisions component. The output of the Decisions component then affects all components with the tagForDecision Field Tag.

Save your Field Tags by pressing Enter (Return) or adding a comma after each entry.

Select this tab to display the component's Display, Data, Actions, and Validation settings panels, as applicable.

Select this tab to see the RBAC RBAC (Role-Based Access Control) is a method to control system access for authorized users. The role in RBAC refers to the levels of access employees have to a network. (role-based access control) settings of the component.

Select this tab to display the component's Notes area. You can use notes to keep your teammates informed.

The Notes editor offers a semi-WYSIWYG (What You See is What You Get) content editor. Built to look like a word processor, this editor lets you create, edit, and format your notes. Notes save when saving the component.

Click this button to undo any unsaved configuration changes and return to the canvas.

The 2 Service Types offered by the Plug-In component are:

• Unqork: Unqork has a number of preconfigured, internal API services. These API calls help you create files, convert files, and access or edit submission data.

• External: The Plug-In component can make an API call to an external source. You must configure these services in Unqork's Services Administration.

TIP  To learn more about Services Administration, search Services Administration in our In-Product Help.

Depending on your choice of the Unqork or External Service Type, an Internal Services or External Services drop-down displays:

• Internal Services: Shows all internal Unqork services available for use. After selecting a service, the Request Type and Data Source URL autofill.

  On selection of an Internal Service, the Pre-Request Transform drop-down displays. In the Pre-Request Transform drop-down, you can select a transform to perform on the submission. The transformed output creates the request body passed to the API call.

• External Services: Shows all services already configured in Services Administration. After selecting a service, the Request Type and Data Source URL autofill.

For an API to bring in data, you need the API's URL information. In this field, enter the API information as obtained from the API documentation. Add additional filters at the end of the URL if you want to drill down to a specific type of data.

Examples of supported inputs include:

• The Property ID of another component in the module. For example, this component can be a trigger, an input for a Micro Decision, or is referenced in a formula.

• Values that are present in the submission object. For example, you can enter currentUser to retrieve information about the end-user from this object.

• Native values generated by Unqork, like entering buttonClick. Unqork creates this value following button-click events.

• Values you want to hard-code into an API call. For example, entering 'no-reply@unqork.com' to map the from.email parameter of a SendGrid call.

  When hard-coding a value, add single quotes around it. This tells the Plug-In the value isn't the Property ID of a component.

API documentation includes mapping information. Mapping information tells your Plug-In component which data to send or retrieve from the API call.

In the case of SendGrid integration, the Mapping column indicates where the Property ID values show up in the email. If you enter 'no-reply@unqork.com' in the Inputs table's Property ID and from.email in the Mapping column, your From address is no-reply@unqork.com.

When set to ON, the end-user must enter a value into the field before navigating ahead or saving the module. Set the toggle to OFF when an entry is optional.

By default, the Required toggle is set to OFF.

When selected, the Plug-In component doesn't pass the field as part of your API call's request body. But, the Plug-In component can still watch for changes made to the value.

When selected, the Plug-In component passes the field as part of the API call's request header. When clear, the Plug-In component passes the field as part of the request body.

Select this setting if you're expecting a base64 file from your API request. Selecting this setting prepares the system for the base64 file, making it easier to convert the file.

For your logic component to recognize an output, you must enter the destination component's Property ID(s) here.

The Property ID entered must match the Property ID used in the output component. Remember, use camel case A naming convention for computer programming. Use camelCase for Property IDs, for example: newUser, lastName, & rdoButton. (stylized as camelCase) without spaces or punctuation.

Map Property IDs according to the API's documentation. Mapping tells your Plug-In what to retrieve from the API call. For the Outputs table, map specific data to put into your output components.

This setting offers handling methods for your outputs:

• Fill: If there's already a value in the output field, the value remains the same. The API call's value doesn't replace the existing value.

• Replace: If there's already a value in the output field, this setting overwrites the value.

• Validate: The Plug-In component maps and validates the value. Validation occurs based on the validation rules set in the output field's settings.

• Disable: This setting maps the response to the field and then disables the field. Use this setting to disable editing of the output field after it populates.

• DynamicRefresh: Triggers the specified panel to refresh its existing content with the provided component definitions (component JSON). The specified Panel component must have Dynamic Refresh enabled.

This setting provides the following options:

• Manual:  The component fires when triggered by another component. For example, using a Button component or Initializer component to trigger the Plug-In component. By default, the Manual Trigger Type is selected.
• Watch: The component fires when there's any action taken on the input component(s) listed in the Inputs table. Actions include entering a new value, editing, or overwriting a saved value. If there are multiple inputs, use the Required setting to specify what inputs must be present before firing.

Enter the Property ID of the component to trigger concurrently when the Plug-In component makes the API call.

Enter the Property ID of the component to trigger after the Plug-In completes the API call. For example, triggering a component to display the data received from the Plug-In component's API call.

Enter the Property ID of a component to trigger on failure of the API call.

The number of milliseconds that pass before the API call times out. If an API call doesn't respond within a reasonable time, you don't want the Plug-In component to continue to wait. Unresponsive API calls can stall your entire application.

The maximum timeout is 120,000 milliseconds.

The number of milliseconds that pass before the component tries the API call again after it failed. Waiting before retrying an API call could give the destination server time to clear the issues that caused it to be unresponsive.

The maximum delay is 10,000 milliseconds.

The number of retries the Plug-In component makes on a failed API call. It's best practice to limit the number of retries, so a continually failing API call doesn't stall your application. Use this setting to limit the number of times the Plug-In component retries the failed API call. If the API call fails all retries, the Error Trigger fires.

The maximum number of retries is 10.

The number of milliseconds that pass before the module loads this component. This is useful if you have a large module and you load several components at the same time.

NOTE  1,000 milliseconds = 1 second.

When set to ON, this setting creates a modal that informs the end-user that the data is processing. The following fields are optional:

• Modal Processing Title: Enter the modal's title.

• Modal Processing Message: Enter the message end-users see while the data is processing.

• Modal Completion Title: Enter the title end-users see after the data processes.

• Modal Error Message: Enter the message end-users see if the data encounters an error while loading.

By default, this toggle is set to OFF.

When set to ON, the end-user's cursor turns into a spinner while data processes.

By default, this toggle is set to OFF.

When set to ON, the page displays a spinning icon while data processes.

By default, this toggle is set to OFF.

If an output comes back empty, you can either have the data store as an empty value or choose not to store the data. By setting this toggle to ON, null or empty strings store as empty values. If set to OFF, the values don't record.

By default, this toggle is set to ON.

When set to ON, the Plug-In component only returns the values set in the Output table, instead of the entire plugin object. Also, none of the Plug-In component's other information logs in the DevTools Console.

When set to OFF, the plugin object logs in the DevTools Console with all response data.

By default, this toggle is set to OFF.

Older API calls are more likely to use XML coding language. The Unqork Designer Platform reads JSON coding language only.

If you know your API call returns XML, set this toggle to ON. When set to ON, the system automatically converts XML to JSON.

By default, this toggle is set to OFF.

When set to ON, the response doesn't convert to and store as base64. Enable this setting when you expect the API call to return a large file, and/or want to store the response in its original file format.

By default, this toggle is set to OFF.

When set to ON, the server sends a single page of data at a time. This helps the page load faster and prevents bloating the end-user's memory. This setting is especially useful for large data sets.

By default, this toggle is set to OFF.

Synchronous processing forces each workflow process to run one at a time. When set to ON, all other processes in your module stop running until the Plug-In component finishes the API call. This style of processing can result in longer processing times. It's best practice when your Plug-In component uses data processed by other components.

By default, this toggle is set to OFF.

When set to ON, the module flattens results into a single record value. When set to OFF, the module leaves the results unflattened into multiple values.

By default, this toggle is set to OFF.

When set to ON, the Plug-In component scans the module for matching values across the API call and Property IDs. Only set this toggle to ON when the module and the API call's data match.

By default, this toggle is set to OFF.

The Plug-In component looks for all specified output values in the data section of the response body. When set to ON, you can remove the data. prefix from your mapping fields. For example, mapping to lastName instead of data.lastName.

By default, this toggle is set to OFF.

When set to ON, an application can makes cross-site access-control requests using credentials, like cookies.