To show provider activity from query execution to network traffic, use Logfile and Verbosity. The examples of common connection errors below show how to use these properties to get more context. Contact the support team for help tracing the source of an error or circumventing a performance issue.

• Authentication errors: Typically, recording a Logfile at Verbosity 4 is necessary to get full details on an authentication error.

• Queries time out: A server that takes too long to respond will exceed the provider's client-side timeout. Often, setting the Timeout property to a higher value will avoid a connection error. Another option is to disable the timeout by setting the property to 0. Setting Verbosity to 2 will show where the time is being spent.

• The certificate presented by the server cannot be validated: This error indicates that the provider cannot validate the server's certificate through the chain of trust. If you are using a self-signed certificate, there is only one certificate in the chain.

  To resolve this error, you must verify yourself that the certificate can be trusted and specify to the provider that you trust the certificate. One way you can specify that you trust a certificate is to add the certificate to the trusted system store; another is to set SSLServerCert.

Firewall Settings

Firewall Server

Specify a firewall name or IP address to authenticate requested connections, if necessary.

If this property is set to a domain name, a DNS request is initiated and the name is translated to the corresponding IP address.

Firewall Password

A password, if authentication is required to connect through a firewall.

If FirewallServer is specified, the FirewallUser and FirewallPassword properties are used to connect and authenticate to the given firewall.

Firewall Port

The TCP port for the firewall FirewallServer -- see the description of the FirewallServer option for details.

Note that the provider sets the FirewallPort to the default port associated with the specified FirewallType. See the description of the FirewallType option for details.

Firewall Type

The type of firewall to connect through.

The applicable values are:

Firewall Type Default Firewall Port:

TUNNEL 80

SOCKS4 1080

SOCKS5 1080

Firewall User

The user name to authenticate with the firewall.

If the FirewallServer is specified, the FirewallUser and FirewallPassword properties are used to connect and authenticate against the firewall.

Proxy Settings

Proxy Auth Scheme

The proxy server authorization scheme (default: BASIC).

This value may be BASIC, DIGEST, NONE, NTLM, NEGOTIATE or PROPRIETARY.

Proxy Auto Detect

This indicates whether to use the default system proxy settings or not. Set ProxyAutoDetect to FALSE to use custom proxy settings. This takes precedence over other proxy settings.

Proxy Password

A password, if authenticating with a proxy server.

If the ProxyServer is specified, the ProxyUser and ProxyPassword properties are used to connect and authenticate against the firewall.

Proxy Port

The TCP port for the proxy ProxyServer (default: 80).

Proxy Server

If a proxy server is given, then the HTTP request is sent to the proxy instead of the specified server.

If this property is set to a domain name, a DNS request is initiated and the name is translated to the corresponding address.

Proxy SSL Type

The SSL type to use when connecting to the proxy server (default: AUTO).

This value may be AUTO, ALWAYS, NEVER, or TUNNEL.

Proxy User

A user name, if authentication is to be used for the proxy.

If a ProxyServer is specified, the ProxyUser and ProxyPassword options are used to connect and authenticate against the firewall.

Connector Logs

Logfile

A path to the log file.

Max log File Size

A string specifying the maximum size in bytes for a log file (for example, 10 MB). When the limit is hit, a new log is created in the same folder with the date and time appended to the end.

Verbosity

The verbosity level that determines the amount of detail included in the log file.

Default: 1

The verbosity level determines the amount of detail that the provider reports to the Logfile. Verbosity levels from 1 to 5 are supported. These are described below:

1 - Setting Verbosity to 1 will log the query, the number of rows returned by it, the start of execution and the time taken, and any errors.

2 - Setting Verbosity to 2 will log everything included in Verbosity 1, cache queries, and HTTP headers.

3 - Setting Verbosity to 3 will additionally log the body of the HTTP requests.

4 - Setting Verbosity to 4 will additionally log transport-level communication with the data source. This includes SSL negotiation.

5 - Setting Verbosity to 5 will additionally log communication with the data source and additional details that may be helpful in troubleshooting problems. This includes interface commands.

The Verbosity should not be set to greater than 1 for normal operation. Substantial amounts of data can be logged at higher verbosities, which can delay execution times.

Connectors like OracleOCI require to add the appRules bin folder to the windows PATH environment variables. Below is the method to update or check the PATH

Navigating to Environment Variables Manually

1. Press Win+ X keys on the keyboard and select System from the list.

2. Inside the System window, click on Advanced system settings located at the left pane.

3. Inside the advanced system settings, click on the Environment Variables button at the bottom and do follow the same procedure to edit environment variables as described above.

In the following window, edit the Path variable:

Using PickLists

appRules includes activities for managing data source picklists (option sets).

The activities are in the appConnector.List module (see User Guide):

- LookupPickListRecord

- IsPickListValueValid

PickLists can be entered manually or generated automatically when data source metadata is created. For example, when a Microsoft Dynamics CRM or Salesforce data sources are created, the system automatically creates the picklists for all entities.

When a picklist entry is defined, you can also enter alternate values associated with the entry. This feature can be used for looking up values for picklist entries. In the example below, when the Account.customertypecode entry is loaded, the three alternate values associated with it are also loaded and can be used any where in your project.

LookupPickListRecord Activity

The LookupPickListRecord activity which is part of the module, allows you to load the values of a picklist into a record. The record values (key/description) can then be used in the running project just like other values (using “DataFieldValue” source value).

IsPickListValid Activity

The IsPickListValid activity which is part of the appConnector.List module, checks whether a value belongs to a picklist. The value can be the key or description of the picklist. The activity returns True or False and can be directly tested using the ActivityResult condition type.

Connect using Azure AD

1 - Define an App in Azure and get your oAuth values

Use the values defined in the Dynamics365 App Registration to get the OAuth client id and secret

2 - Get the OAuth Access Token in appRules

2.1 - Standard oAuth Flow

Use Getting the oAuth Access and Refresh Tokensin order to get the proper connection properties

2.2 - Client OAuth Flow

Client credentials refers to a flow in OAuth where there is no direct user authentication taking place. Instead, credentials are created for just the app itself. All tasks taken by the app are done without a default user context. This makes the authentication flow a bit different from standard.

All permissions related to the client oauth flow require admin consent.

In your App Registration in portal.azure.com, navigate to API Permissions and select the Microsoft Graph permissions. There are two distinct sets of permissions - Delegated and Application permissions. The permissions used during client credential authentication are under Application Permissions. Select the applicable permissions you require for your integration.

In addition to setting the standard OAuth client id and secret, to use client credentials you must also set the following connection properties:

• OAuthGrantType: Set this to CLIENT.

• AzureTenant: Set this to the tenant you wish to connect to.

When you authenticate using client credentials, there is no Web flow. Authentication with client credentials will take place automatically like any other connection, except there will be no window opened prompting the user. Because there is no user context, there is no need for a browser popup. Connections will take place and be handled internally.

Connect using MSI Authentication

If you are running the source on an Azure VM, you can leverage Managed Service Identity (MSI) credentials to connect:

• AuthScheme: Set this to AzureMSI.

The MSI credentials will then be automatically obtained for authentication.

Custom AzureAD Applications

Create a Custom AzureAD App

Follow the steps below to obtain the AzureAD values for your application, the OAuthClientId and OAuthClientSecret.

1. Log in to https://portal.azure.com.

2. In the left-hand navigation pane, select Azure Active Directory, then applicationRegistrations, and click New registration.

3. Enter an application name and select the desired tenant setup. When creating a custom AzureAD application in Azure Active Directory, you can define whether the application is single- or multi-tenant. If you select the default option, "Accounts in this organizational directory only", you must set the AzureTenant connection property to the Id of the Azure AD Tenant when establishing a connection. Otherwise, the authentication attempt fails with an error. If your application is for private use only, "Accounts in this organization directory only" should be sufficient. Otherwise, if you want to distribute your application, choose one of the multi-tenant options.

4. Set the redirect url to http://localhost:33333, the provider's default. Or, specify a different port and set CallbackURL to the exact reply URL you defined.

5. Click Register to register the new application. This opens an application management screen. Note the value in Application (client) ID as the OAuthClientId and the Directory (tenant) ID as the AzureTenant.

6. Navigate to the "Certificates & Secrets" and define the application authentication type. There are two types of authentication available: using a client secret or a certificate. The recommended authentication method is using a certificate.

   • Option 1: Upload a certificate: In "Certificates & Secrets", select Upload certificate and the certificate to upload from your local machine.

   • Option 2: Create a new application secret: In "Certificates & Secrets", select New Client Secret for the application and specify its duration. After saving the client secret, the key value is displayed. Copy this value as it is displayed only once. You will need it as the OAuthClientSecret.

7. Select API Permissions > Add. If you plan for your application to connect without a user context, select Application Permissions (OAuthGrantType = CLIENT). Otherwise, use the Delegated permissions.

8. Select the Azure Application and add the Have full access to the Application service permission.

9. Save your changes.

10. If you have selected to use permissions that require admin consent (such as the Application Permissions), you can grant them from the current tenant on the API Permissions page. Otherwise, follow the steps under "Admin Consent".

Custom AzureAD Service Principal Applications

When authenticating using an Azure Service Principal, you must create both a custom AzureAD application and a service principal that can access the necessary resources. Follow the steps below to create a custom AzureAD application and obtain the connection properties for Azure Service Principal authentication.

Create a Custom AzureAD App with an Azure Service Principal

Follow the steps below to obtain the AzureAD values for your application.

1. Log in to https://portal.azure.com.

2. In the left-hand navigation pane, select Azure Active Directory then App Registrations and click New registration.

3. Enter an app name and select Any Azure AD Directory - Multi Tenant. Then set the redirect url to http://localhost:33333, the provider's default.

4. After creating the application, copy the Application (client) Id value displayed in the "Overview" section. This value is used as the OAuthClientId

5. Define the app authentication type by going to the "Certificates & Secrets" section. There are two types of authentication available: using a client secret and using a certificate. The recommended authentication method is via a certificate.

   • Option 1 - Upload a certificate: In "Certificates & Secrets", select Upload certificate and the certificate to upload from your local machine.

   • Option 2 - Create a new application secret: In "Certificates & Secrets", select New Client Secret for the application and specify its duration. After saving the client secret, the key value is displayed. Copy this value as it is displayed only once. You will use it as the OAuthClientSecret.

6. On the Authentication tab, make sure to select Access tokens (used for implicit flows).

Executing Stored Procedures

appRules supports the execution of stored procedures. For database engines that support stored procedures, appRules includes the ExecuteStoredProcedure activity for executing stored procedures. If the stored procedure returns records, the records and the fields they contain can be read from the database and utilized in appRules just like any other records and fields.

ExecuteStoredProcedure Activity

For example, to execute a stored procedure in SQL Server, drag and drop the ExecuteStoredProcedure activity from the SQL Server Toolbox on to the designer and configure the properties.

This appRules process is common to the Datasources using standard oAuth access (vs Client oAuth flow) in order to get access and refreshtokens:

Click on the Connection Parameters button from the datasource definition window:

GetAuthorizationURL Procedure (if required)

Click on "Execute" to get the authorization URL, you then will be asked to connect with your credentials to the authorization environment

You then obtain your access and refresh tokens, click on the "Return" to update your datasource definition with the obtained values

The values are copied to the destination properties, you can then click on the below button to test your connection:

Click Save Settings to save your datasource (Connection Settings window) or generate the metadata (Refresh Metadata window)

Kerberos

To authenticate using Kerberos, set the following properties:

• KerberosKDC: Set this to the host name or IP Address of your Kerberos KDC machine.

• KerberosSPN: Set this to the service and host of the Greenplum Kerberos Principal. This is the value prior to the '@' symbol (for instance, ServiceName/MyHost) of the principal value (for instance, ServiceName/MyHost@EXAMPLE.COM).

Retrieve the Kerberos Ticket

You can use one of the following options to retrieve the required Kerberos ticket.

MIT Kerberos Credential Cache File

This option enables you to use the MIT Kerberos Ticket Manager or kinit command to get tickets. Note that you do not need to set the User or Password connection properties with this option.

1. Ensure that you have an environment variable created called KRB5CCNAME.

2. Set the KRB5CCNAME environment variable to a path pointing to your credential cache file (for instance, C:\krb_cache\krb5cc_0 or /tmp/krb5cc_0). This file is created when generating your ticket with MIT Kerberos Ticket Manager.

3. To obtain a ticket, open the MIT Kerberos Ticket Manager application, click Get Ticket, enter your principal name and password, then click OK. If successful, ticket information appears in Kerberos Ticket Manager and is stored in the credential cache file.

4. Now that you have created the credential cache file, the provider uses the cache file to obtain the Kerberos ticket to connect to Greenplum.

As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the provider uses the specified cache file to obtain the Kerberos ticket to connect to Greenplum.

Keytab File

If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do so, set the User property to the desired username and set the KerberosKeytabFile property to a file path pointing to the keytab file associated with the user.

User and Password

If both the KRB5CCNAME environment variable and the KerberosKeytabFile property have not been set, you can retrieve a ticket using a user and password combination. To do this, set the User and Password properties to the user/password combination that you use to authenticate with Greenplum.

Cross-Realm

More complex Kerberos environments may require cross-realm authentication where multiple realms and KDC servers are used (e.g., where one realm/KDC is used for user authentication and another realm/KDC is used for obtaining the service ticket).

In such an environment, set the KerberosRealm and KerberosKDC properties to the values required for user authentication. Also set the KerberosServiceRealm and KerberosServiceKDC properties to the values required to obtain the service ticket.

App registration in Azure active directory and definition of an application user in Microsoft powerapps are required in order to access the Dynamics365 applications in appRules, this section describes all the steps to do so.

1 SETTING UP THE AZURE APP REGISTRATION

Step 1:

Create an App registration in Azure, under Azure Active Directory.

Enter an app name and set the radio button for "Any Azure AD Directory - Multi Tenant". Then set the redirect url (Callback url) to something such as http://localhost:33333, the provider's default.

Step 2:

Once created, copy the Application (client) ID of the new App registration. This will be used later as the Client ID.

Step 3:

Navigate to Certificates & secrets and click New client secret, under Client secrets.

Enter a description for the client secret (optional).

Select the expiry date for the client secret. The maximum you can select is 24 months. After the expiry, a new secret will need to be generated, and any applications using the secret will need to be updated.

Step 4:

Once the secret is created, copy the Value. This will be used as the Client Secret later. This is the only chance you’ll have to copy the secret, so be sure to save it somewhere safe. If you lose the value, you can always generate another later.

Step 5:

Navigate to API permissions and select Add a permission.

From the Request API permissions screen, under Microsoft APIs, select the Dynamics365 application (Dynamics CRM in the below example)

Under Delegated permissions, select user_impersonation, and then Add permissions.

2 ADDING THE APPLICATION USER TO DYNAMICS 365

Step 6:

Open the Power Platform Admin Center as a System Administrator, and select your Dynamics 365 Environment, then select Settings.

Navigate to Application users, under Users + permissions.

Step 7: Click New app user from the list of Application users

From the Create a new app user screen, click Add an app and select the App you created earlier.

Select the Business unit to add the app user to.

Select the Security role(s) to assign to the user once created : System Administrator rôle is required to generate the metadata model (appRules Data Sources).

Click Create, and you’ll see the user has been added to your environment. You’ll also notice that the App ID is the same Application (client) ID copied in step 2

Step 8:

You should now have the Application ID and the Client Secret copied from step 4.

Combine these with your Environment URL, and you’ll have everything you need to grant your application access to your Dynamics 365 environment.