Email Adapter
An Email Integration Service empowers a user to send emails (like notification, status mails) from the client app. You can also know the status of the email which was sent before through Email service. The email requests are sent to the Quantum Fabric server which in-turn redirects them to the Quantum Engagement server.
While configuring an Email service, you can pass the email ID, subject , message and even attachments as input parameters based on which the email will be delivered to the respective recipients. However, the client app user can configure the body of the email from the client app or any design time environment.
Perform the following steps to configure an Email Service:
- Configure a Service Definition for Email Service.
- Configure Operations for the Service definition.
NOTE: This is a static adapter and the default configurations that appear while configuring the operations are sufficient to get the required output from the service. You can leave the remaining fields as is.
Configure a Service Definition
To configure the Email Adapter in the Integration service definitiontab, follow these steps:
- In the Name field, provide a unique name for your service.
- From the Service Type list, select Email.
- In the Authentication section, the Use Existing Identity Provider list displays the existing Identity services available in the Fabric App. Select an Identity Service from the list. This will add a security layer onto your Email service. If you select an Identity Service, you must provide appropriate login details to send an email from the client app.
-
The Advanced section contains the following additional configurations. You can configure them if required:
Field Description Custom Code Custom Code enables you to specify dependent JAR.
To specify dependent JAR, select the JAR containing preprocessor or postprocessor libraries from the drop-down list, or click Upload New to browse the JAR file from your local system. This step allows you to further filter the data sent to the back end.
IMPORTANT: Make sure that you upload a custom JAR file that is built on the same JDK version used for installing Quantum Fabric Integration.
For example, if the JDK version on the machine where Quantum Fabric Integration is installed is 1.6, you must use the same JDK version to build your custom jar files. If the JDK version is different, an unsupported class version error will appear when a service is used from a device.Throttling API throttling enables you to limit the number of request calls within a minute. If an API exceeds the throttling limit, it will not return the service response.
- To specify throttling in Quantum Fabric Console, follow these steps:
-
In the Total Rate Limit text box, enter a required value. With this value, you can limit the number of requests configured in your Quantum Fabric console in terms of Total Rate Limit.
- In the Rate Limit Per IP text box, enter a required value. With this value, you can limit the number of IP address requests configured in your Quantum Fabric console in terms of Per IP Rate Limit.
-
- To override throttling in App Services Console, refer to Override API Throttling Configuration.
NOTE: Enable API throttling in a clustered environment by configuring the KONY_SERVER_NUMBER_OF_NODES property in the server_configuration table available in Admin database. This property indicates the number of nodes configured in the cluster. The default value is 1.
NOTE: All options in the Advanced section are optional.
- To specify throttling in Quantum Fabric Console, follow these steps:
- In the Description field, provide a suitable description for the service.
- Click Save or Save and Add Operation to save your service definition.
Configure Operations for the Service definition
- Click Save and Add Operation in your service definition page to save your service definition and display the New Operation tab for adding operations.
OR
Click Add Operation to add a new operation or from the tree in the left pane, click Add > Add New Operation. - In Operations List tab, select the required operation and click Add Operation. A new operation is created and listed in the Operations List tab with Email_Operations as default prefix. The operations available are:
- sendEmail - You can use this operation to configure an email template which will be used by the client app to send emails.
- getEmailStatus - You can use this operation to know the status of the emails that were sent.
- Select the new operation that was added to configure the operation. Refer to the following sections to know more about the configurations you can do for each operation.
Configure Operations
In the sendEmail operation you can configure the details like Message, Attachments, and more. The details defined here act as the template for the email.
Perform following steps to configure a sendEmail or getEmailStatus operation:
- Click the required operation from the operations list. The operation details page appears.
- Provide the following information in the details page:
Field Description Name The operation name appears in the Name field. You can modify the name, if required. Operation Security Level It specifies how a client must authenticate to invoke this operation.
Select one of the following security operations in the Operation Security Level field.- Authenticated App User – It restricts the access to clients who have successfully authenticated using an Identity Service associated with the app.
- Anonymous App User – It allows the access from trusted clients that have the required App Key and App Secret. Authentication through an Identity Service is not required.
- Public – It allows any client to invoke this operation without any authentication. This setting does not provide any security to invoke this operation and you should avoid this authentication type if possible.
- Private - It blocks the access to this operation from any external client. It allows invocation either from an Orchestration/Object Service, or from the custom code in the same run-time environment.
NOTE: The field is set to Authenticated App User, by default.
Mapped To Displays the operation with which the adapter is linked with in the back end. This field is non editable. Action Displays the type of connector (service or object) with which this operation is linked with. This field is non editable.
-
The Advanced section contains the following additional configurations related to request (or) response operations. You can configure them if required:
Custom Code Invocation You can add pre and post processing logic to services to modify the request inputs. When you test, the services details of various stages in the service execution are presented to you for better debugging. All options in the Advanced section are optional. For more details, refer to Preprocessor and Postprocessor. Additional Configuration Properties Additional Configuration Properties allows you to configure service call time out cache response. For information on different types of configuration properties, refer Properties. Front-end API Front-end API allows you map your endpoint (or) backend URL of an operation to a front-end URL. For detailed information, refer Custom Front-end URL. Server Events Using Server Events you can configure this service to trigger or process server side events. For detailed information, refer Server Events. NOTE: All options in the Advanced section for operations are not mandatory.
- Enter the Description for the operation.
In the Request Input tab, you can configure the parameters like To, CC, Message, Attachments and more which are required to send an email. The details defined here act as the template for the email. You can define the value of each parameter here directly, or provide the information of the source from where the information can be retrieved.
You can define the Body and Header related input parameters from the Request Input tab. By default, the Body tab is selected. You can do the following to configure the input parameters in the Body tab:
Field | Description |
---|---|
Name | The name for the request input parameter. |
Value |
The options available in the Value list determine the source from where the value of the input parameter must be retrieved. Select request or session or Identity.
NOTE: When you start editing this field, dependent identity services are auto populated. NOTE: The field is set to Request, by default. NOTE: For more information on Externalizing Identity Services, refer to Replace the Identity Service references in a Fabric app. |
Test Value | A test value is used for testing the service. |
Default Value | The default value is used in the run-time when the service cannot find the defined header parameter value. |
Data Type |
Select one of the following data types.
|
Collection ID | Determines the location of the input value if there is a list of collections in the input received. |
Record ID | Determines the location of the input value if there is an array of records in the input received. |
Description | Enter the description for the request. |
The following input parameters are displayed by default for Email_Operations_sendEmail operation:
- To
- CC
- message
- subject
- attachments
The following input parameters are displayed by default for Email_Operations_getEmailStatus operation:
- requestID
Click the Header tab to configure the header parameters. The parameters configured here will be appended to the header of the input request. Configure the following fields to define header parameters:
Field | Description |
---|---|
Name | The name for the request input parameter. |
Value |
The options available in the Value list determine the source from where the value of the input parameter must be retrieved. Select request or session or Identity.
NOTE: The field is set to Request, by default. |
Test Value | A test value is used for testing the service. |
Default Value | The default value is used in the run-time when the service cannot find the defined header parameter value. |
Description | Enter the description for the request. |
In the Response Output tab, you can configure the output parameters that you are expecting the service to return after the service is executed.
By default, the following output parameters are returned from the back end for Email_Operations_sendEmail operation:
- Email Result
- requestId
- message
By default, the following output parameters are returned from the back end for Email_Operations_getEmailStatus operation:
- Email Status
- Email Count
- Message Response
You can configure the following information about each output parameter:
Field | Description |
---|---|
Name | The name for the response output parameter. |
Path | Determines the path where you want to store the output value from the response. |
Scope |
It determines the how you want to use the output value. It has the following options:
|
Data Type |
Select one of the following data types.
|
Collection ID | Determines the location of the output value if there is a list of collections in the output received. |
Record ID | Determines the location of the output value if there is an array of records in the output received. |
Description | Enter the description for the request. |
Other common options available in the Request Input and Response Output tabs are as follows:
- Add Parameter: Click Add Parameter to add an entry (if the entries for input and the output tabs does not exist).
- Copy, Paste: Select the check box of an entry, and click Copy and Paste, if you want to make duplicate entries.
- Delete: Select the check box of an entry and click Delete, if you want to delete an entry.
- Enable pass-through: Select the Enable pass-through check box if you want to forward the body of the client's request to backend as it is. For more details on API Proxy service, refer to How to Enable Pass-through Proxy for Operations.