1 of 11

ERP

NetSuite

1 Connecting to NetSuite

1.1 SuiteTalk vs SuiteQL

SuiteTalk is the older SOAP based service we use to communicate with NetSuite. It has broad support for a lot of entities and full support for insert/update/delete. However, the tools offered for selecting data are fairly weak, which yields very poor performance during a SELECT. There is not a great way to join tables. Grouping and aggregating data is unavailable with this API, which means to support them they must be done entirely client side.

SuiteQL is the newer API. It offers a SQL like method of communicating with the service, which allows for more rich join support, as well as group by and aggregations. It also fully supports retrieving only the columns you want to select. This makes it much more performant for selecting data vs SuiteTalk. However, it only supports selecting data.

You may specify which API to connect to by setting Schema. It is recommended to use SuiteQL if you are just retrieving data, and SuiteTalk if you need to both retrieve and modify. Please be aware that each API has different available connection options as described below.

1.2 NetSuite Web Services Permissions

The provider communicates with NetSuite through the NetSuite Web services. This means that any connecting user must have permissions on the specified AccountId to connect through NetSuite Web services.

Permissions may be configured for a role in NetSuite under Setup --> Users/Roles --> Manage Roles. This page contains two lists of permissions, first the most commonly required, and then other permissions for fuller support. Please be aware that it is not possible for us to provide an exhaustive list of permissions as NetSuite adds support for new entities and permissions with each version.

1.2.1 Most Commonly Required Permissions

Note: Most of the following permissions fall under the Permissions --> Setup section for a role.

1.2.2 Other Permissions

Create or edit a role for Web services permissions

Log into NetSuite and under Setup go to User/Roles -> Manage Roles -> New. Alternatively, edit an existing role.
Click Permissions -> Setup and add the "SOAP Web Services" and "REST Web Services" permissions.
Add other permissions that are needed for interacting with various entities and transactions.
Under Setup, go to User/Roles -> Manage Users and select the user.
On the Access tab, add the newly created role and save the user.

2 Authenticating to NetSuite

2.1 Basic Authentication

Note: This section is only applicable to SuiteTalk. SuiteQL requires OAuth or Token Authentication.

As of 2020.2, NetSuite will no longer support user / password connections. While the connector will continue to support User/Password connections for Version set to values lower than 2020.2, it is recommended that all customers migrate to OAuth and Token Based Authentication mechanisms described below. Set the AuthScheme to Basic to support user / password credentials, but also be aware that due its removal in newer versions, you must also manually specify a lower Version to use it.

2.2 Token Based Authentication

Token Based Authentication or TBA may be used with either SuiteTalk or the SuiteQL Schema. Set the AuthScheme to Token to support TBA. Token Based Authentication is performed by creating the OAuthClientId, OAuthClientSecret, OAuthAccessToken and OAuthAccessTokenSecret directly within the NetSuite UI by an administrator with permissions to do so.

An older model that may still be used by admins is to simply create and assign a token directly in the NetSuite UI. Doing this will allow you to bypass the normal steps for generating an OAuth Access Token. This may be desireable if you would like to have more direct control over giving access, although it will always require manual steps to be taken in the UI each time. Instead, follow these steps to create a token in the UI:

In NetSuite, log in as an administrator role and navigate to Setup --> Company --> Enable Features --> SuiteCloud --> Manage Authentication. Make sure Token-Based Authentication and TBA: Authorization Flow are checked and save changes.
Navigate to Setup --> Integration --> Manage Integrations.
Create a new integration and select Token-Based Authentication.
When the integration is created, the Consumer Key and Consumer Secret displayed will map directly to the OAuthClientId and OAuthClientSecret connection properties. Write these down.
Create a token role by navigating to Setup --> User/Roles --> Manage Roles and either create a new role or edit an existing role.
Under Permissions --> Setup, the role must have the User Access Token: Full, Access Token Management: Full, and Web Services: Full permissions.
Add the role to a user under Lists --> Employees --> Employees. Select to edit an employee and add the new token role under Access --> Roles.
Navigate to Setup --> User/Roles --> Access Tokens and create a new access token. Select the application name as the integration that was created earlier, and the same user and role that were updated in the previous steps.
After creating the access token, a Token Id and Token Secret will be displayed. These map directly to the OAuthAccessToken and OAuthAccessTokenSecret. Write these down.

After creating the access token, a connection can now be made using the values obtained from the previous steps. Specify these connection properties at a minimum to connect:

AccountId specifying the account to connect to.
OAuthClientId the Consumer Key displayed when the application was created.
OAuthClientSecret the Consumer Secret displayed when the application was created.
OAuthAccessToken the Token Id when the access token was created.
OAuthAccessTokenSecret the Token Secret when the access token was created.

2.3 OAuth Authentication

To support OAuth, set the AuthScheme to OAuth. NetSuite offers two forms of OAuth authentication: 1.0, and 2.0. Token Based Authentication is actually just OAuth 1.0 with the OAuthAccessToken and OAuthAccessTokenSecret created within the NetSuite UI instead of at runtime. OAuth 1.0 is available for both SuiteTalk and SuiteQL. OAuth 2.0 is only available to SuiteQL. For this reason, OAuthVersion defaults to empty, meaning that if you set Schema to SuiteTalk, OAuth 1.0 will be used, and if you set Schema to SuiteQL, OAuth 2.0 will be used. This can be overridden by explicitly setting the OAuthVersion connection property, which may be desireable if switching between SuiteTalk and SuiteQL, or for users upgrading from a previous version where only OAuth 1.0 was supported for SuiteQL.

Be aware that even though you may change the OAuthVersion, OAuth 2.0 is not available on SuiteTalk even if you set it with Schema set to SuiteTalk since the API does not support it.

Register your NetSuite app on Setup --> Integrations --> Manage Integrations. Select the checkbox for each of Token-Based Authentication and TBA: Authorization Flow for OAuthVersion 1.0 support. Check the checkboxes for Authorization Code Grant, Restlets, and Rest Web Services for OAuthVersion 2.0 and set an appropriate Redirect URI. Then, obtain the following connection properties:

OAuthClientId: Set this to the Consumer Key assigned when you registered your app.
OAuthClientSecret: Set this to the Consumer Secret assigned when you registered your app.
CallbackURL: Set this to the Redirect URI defined when you registered your app such as http://localhost:33333. Note that this must be an exact match including any trailing '/' characters.

Set Callback URL to http://localhost:portnumber and set CallbackURL to match. You can specify any port available.

3 Concurrent Requests

NetSuite allows only a certain amount of concurrent requests per account, which is configurable per integration connection (generally defaulting to 5). If the maximum, concurrent requests are currently in use when another one is attempted to be used, an error stating "Only one request may be made against a session at a time" may be thrown on the next connection. The provider will attempt to account for this and stagger additional requests so as not to exceed the concurrent request limit. But it is not always possible to do this correctly if the account is being connected to from multiple machines or applications.

4 Asynchronous Services

Slow NetSuite response times extend to inserts, updates, and deletes as well. This can be especially noticeable when using batch processing. When inserting, updating, or deleting multiple records at a time, it may be worthwhile to set UseAsyncServices to true.

5 PROPERTIES

The following are the connection properties for NetSuite_SuiteQL. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

Odoo

To connect, set the Url to a valid Odoo site, User and Password to the connection details of the user you are connecting with, and Database to the Odoo database.

Access Rights

In order for the provider to determine what models you can access in Odoo, the user you connect with must have permissions to read from "ir.model.access" (an internal Odoo model that governs access rights). Normally this is reserved for administrators, but it can be granted to any user by creating a Service group:

As an administrator, open the Odoo settings page and enable "developer mode"
Open the Groups page and create a new group
Set the Application to "Administration" and the name to "Service Access"
Add any users who need Service access in the Users tab
In the Access Rights tab, add an entry for the "ir.model.access" object, check Read Access, and give it the name "Inspect Models"
Save the group

If making this change is not possible, then you should set the CheckPermissions option to false. That will list all models in Odoo as tables, regardless of what permissions your user actually has for those models.

Acumatica

1 Connecting to Acumatica

In order to connect to the Acumatica data source, you will first need to specify the below connection properties.

Url: (Required) The base URL for the Acumatica ERP instance. For example: https://domain.acumatica.com/entity/.
Schema: (Optional) There are two schemas which contains different data. The default one is REST which uses the Acumatica REST Contract Based API and the OData which uses the Acumatica OData API. The OData schema is used to query Acumatica Generic Inquiries.
Company: (Partially required) Set this to the name of your company or tenant. It is required if Schema is set to "OData".
EndpointVersion: (Optional) The version of the Web Services endpoint. For example: 17.200.001. This is applicable only for the "REST" schema.
EndpointName: (Optional) The name of the Web Services endpoint. For example: Default. This is applicable only for the "REST" schema.

To find out the EndpointVersion and EndpointName for your Acumatica instance, log into Acumatica in a web browser, and then navigate to the 'Web Service Endpoints' screen. If necessary, navigate to this screen by editing the web browser URL and replacing ScreenId=00000000 (the homepage) with ScreenId=SM207060. If you are redirected back to the homepage, this means your user does not have the necessary permissions to access web services. Under Endpoints properties get the Endpoint Name and Endpoint Version.

2 Authenticating to Acumatica

There are two authentication methods available for connecting to Acumatica data source, Basic and OAuth.

2.1 Authenticating with User Credentials

Set the AuthScheme to Basic and set the User and Password to your login credentials.

2.2 Authenticating with OAuth

The Acumatica data source also supports the OAuth 2.0 authentication standard. To authenticate using OAuth, you will need to create and configure a custom OAuth app, then set AuthScheme to OAuth and fill in the OAuth credentials.

3 Register an OAuth Application

You can follow the procedure below to obtain the OAuth client credentials, the OAuthClientId and OAuthClientSecret.

You use the Connected Applications (SM303010) form to register an OAuth 2.0 or OpenID Connect client application. To register a client application in Acumatica ERP, you need to know the OAuth 2.0 flow that this application implements.
When you are registering the client application, you have to be logged in to the tenant whose data the client application needs to access.
On the System tab, click Integration. In the navigation pane, navigate to Configure > Connected Applications.
In the Client Name box, type the name of the registered application.
In the OAuth 2.0 Flow box, select Authorization Code.
On the Secrets tab, do the following for each client secret you want to add:
1. On the tab toolbar, click Add Shared Secret. The Add Shared Secret dialog box opens.
2. In the Description box, type the description of the shared secret.
3. Optional: In the Expires On (UTC) box, enter the date and time on which the secret expires.
4. Copy and save the value that is displayed in the Value box. The client application should use this client secret for authentication in Acumatica ERP.
Click OK to save the secret and close the dialog box.
On the Redirect URIs tab, do the following for each redirect URI you want to add: On the tab toolbar, click Add Row. In the Redirect URI column of the new row, type the exact redirect URI to which Acumatica ERP should redirect the client application after the client application has been authorized. The redirect URI must be absolute and must not have the fragment part (the part preceded with #). On the form toolbar, click Save. Notice that the client ID has been generated in the Client ID box. The client application should use this client ID along with the client secret for authentication in Acumatica ERP.

In order to obtain a token, the client application needs to call the Oauth2 endpoint using various grants depending on the authentication scenarios required. The default OAuthGrantType is CODE, which requires you to follow the steps below. After setting the following connection properties, you are ready to connect:

OAuthClientId: Set this to your clientId.
OAuthClientSecret: Set this to your clientSecret.
InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken connection property.
CallbackURL: Set this to the redirect URI configured in the oauth application.

When you connect, the connector completes the OAuth process:

Extracts the access token from the CallbackURL.
Obtains a new access token when the old one expires.
Saves OAuth values along with geolocation in OAuthSettingsLocation to be persisted across connections.

The following are the connection properties for Acumatica. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

Dynamics NAV

1 Connecting to Dynamics NAV

Before the provider can connect with Dynamics NAV, OData services need to be enabled on the server. Once OData Services are enabled, the provider will be able to query any services that are published on the server.

In addition, specify a Url to a valid Dynamics NAV server organization root (e.g. http://MyServer:7048) and a ServerInstance (e.g. DynamicsNAV71). If there is not a Service Default Company for the server, set the Company (e.g. 'CRONUS Canada, Inc.') as well.

In a multitenant installation, specify the tenant Id in Tenant (e.g. 'Cronus1').

2 Authenticating to Dynamics NAV

To authenticate, set the User and Password properties to valid Dynamics NAV logon credentials or Windows user credentials. Select the appropriate authentication method in AuthScheme.

3 Auth Schemes

The available authentication schemes are configured in IIS where Dynamics NAV is hosted. In IIS you can select to enable or disable Digest, Basic, Windows, or Anonymous authentication. Please consult with your Dynamics NAV admin to determine which authentication scheme is appropriate for you. Set AuthScheme to one of the following:

NEGOTIATE (default) - It is part of the Windows authentication, also known as Kerberos.
BASIC - Basic authentication.
DIGEST - Digest authentication.
NTLM - Part of the Windows authentication.
NONE - Anonymous authentication.

The following are the connection properties for Dynamics NAV. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

Dynamics GP

1 Connecting to Dynamics GP

To connect set the Url to the Web services endpoint; for example, http://{servername}:{port}/Dynamics/GPService. Additionally, set CompanyId; you can obtain this value in the company setup window: Click Tools -> Setup -> Company.

2 Authenticating to Dynamics GP

The Dynamics GP data source supports the following authentication methods: Anonymous Authentication, WS-Security (WSS) Authentication, Basic Authentication, NTLM User Authentication, Digest and Negotiate (Kerberos).

2.1 Anonymous Authentication

In some situations, Dynamics GP may be connected to without setting any authentication connection properties. To do so, simply set the AuthScheme to "None", and you are ready to connect.

2.2 Authenticate using WS-Security (WSS) Authentication

Set the User and Password to connect and set AuthScheme to "WSS".

Note: WSS Authentication is the default authentication scheme.

2.3 Authenticate using Basic Authentication

Set the User and Password to connect and set AuthScheme to "Basic".

2.4 Authenticate using Windows (NTLM)

Set the Windows User and Password to connect and set AuthScheme to "NTLM".

2.5 Authenticate using Digest Authentication

Set the User and Password to connect and set AuthScheme to "Digest".

2.6 Authenticating with Kerberos

To authenticate to Dynamics GP using Kerberos, set the following properties:

AuthScheme: Set this to KERBEROS
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 Dynamics GP Kerberos Principal. This will be the value prior to the '@' symbol (for instance, ) of the (for instance, ).

2.6.1 Retrieve the Kerberos Ticket

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

2.6.2 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 won't need to set the User or Password connection properties with this option.

Ensure that you have an environment variable created called KRB5CCNAME.
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 will be created when generating your ticket with MIT Kerberos Ticket Manager.
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 will appear in Kerberos Ticket Manager and will now be stored in the credential cache file.
Now that the credential cache file has been created, the provider will use the cache file to obtain the kerberos ticket to connect to Dynamics GP.

As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the provider will use the specified cache file to obtain the kerberos ticket to connect to Dynamics GP.

2.6.3 Keytab File

If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do this, 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.

2.6.4 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 combo that you use to authenticate with Dynamics GP.

2.6.5 Cross-Realm Authentication

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 used for obtaining the service ticket).

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

The following are the connection properties for Microsoft Dynamics GP. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

Microsoft Dynamics 365 FinOp

See Microsoft Dynamics 365 Sales

Microsoft Dynamics365 Business Central

Connecting to Dynamics 365 Business Central

To connect to data, specify OrganizationUrl. The OrganizationUrl should be either the endpoint to your business central account such as https://businesscentral.dynamics.com/abc123/, or it should reference the web services root. Please see Business Central Endpoints for more details on how to specify the OrganizationUrl and which endpoints are available.

If you have multiple companies in your organization, you must also specify the Company to indicate which company you would like to connect to. Company does not need to be specified if you have only one company.

User and Access Key Authentication

To authenticate to Dynamics 365 Business Central, you may provide the User and AccessKey connection properties. Microsoft recommends these for testing and development purposes, but discourages their use for production environments.

To obtain the User and AccessKey values, navigate to the Users page in Dynamics 365 Business Central and then click on Edit. The User Name and Web Service Access Key values are what you will enter as the User and AccessKey connection string properties. Note that the User Name is not your email address. It is a shortened user name.

OAuth Authentication

Microsoft recommends for production use cases to use OAuth authentication. Below is an explanation of how to connect via OAuth. OAuth requires the authenticating user to interact with Dynamics365. To connect, you will need to register an app in Azure. Below we list the steps on how to register an App on Azure.

Create an Azure App using the New Portal

Log in to https://portal.azure.com.
On the left hand side, select Azure Active Directory, then App Registrations and click the Add button.
In the menu presented, give a name to your app, select app/web api
set the CallbackURL to the appRulesPortal URL (example: http://localhost:8080)
Now go to Keys and create a key for the app. You can select to create a key with a limited duration, or one that never expires. Selecting one that never expires will prevent you from having to create further keys in the future and is recommended.
After the key is saved, a value for the key will be displayed once. Save this value or write it down. You will also need to save the value of the Application Id currently displayed.
Now select required permissions and Add. Under Select an API, choose Business Central.
Once the Dynamics365 app has been added to the required permissions, select it from the menu and under Delegated Permissions, select Access Business Central as organization users.
Save your changes.

Authenticate to Dynamics365 in appRules Portal when creating a new datasource

Set the following connection properties:

OrganizationUrl: The organization url you are connecting to such as https://[organization].crm.dynamics.com.
OAuthClientId: Set this to the application id displayed for the app you created in Azure.
OAuthClientSecret: Set this to the value of the key you created in Azure.

Use the following process to Get your access and refresh tokens

The connector will use the refresh token to obtain a new access token once the current access token has expired. This is generally the best method of configuring OAuth.

Connect using MSI Authentication

If you are running Dynamics 365 Business Central 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.

Other properties (Proxy...) are detailed in section common properties

Business Central Endpoints

Dynamics 365 Business Central supports several different endpoints to connect to data, with the two main categories being the Common Service endpoints, and the Web Services endpoints. Beyond that, each set of endpoints are split into Production and Testing endpoints. Production endpoints require an OAuth connection, whereas Testing endpoints may be connected to via User and AccessKey. Note that both Production and Testing endpoints access and interact with the same data - they just have different restrictions on what authentication methods are allowed.

The OrganizationUrl by default will attempt to resolve to a Common Service Production endpoint if any https://businesscentral.dynamics.com/ URL is specified. However, this may be configured by modifying the EndpointType. In addition, specifying any https://api.businesscentral.dynamics.com/ will override both EndpointType and UseSandbox as the specified OrganizationUrl supplied will be used without alteration.

Common Service Endpoints

Common Service endpoints contain the business data associated with Dynamics 365 Business Central. For instance, accounts, sales orders, and sales invoices will all be found on the Common Service.

Common Service Endpoints - Production

https://api.businesscentral.dynamics.com/v2.0/{environment name}/api/v1.0
https://api.businesscentral.dynamics.com/v1.0/api/v1.0
https://api.businesscentral.dynamics.com/v1.0/sandbox/api/v1.0

Common Service Endpoints - Testing

https://api.businesscentral.dynamics.com/v2.0/{tenant id}/{environment name}/api/v1.0
https://api.businesscentral.dynamics.com/v1.0/{tenant id}/api/v1.0
https://api.businesscentral.dynamics.com/v1.0/{tenant id}/sandbox/api/v1.0

Note: The Tenant Id is the id of your tenant in Azure that the Business Central app is available on. This may be obtained by logging into portal.azure.com, selecting your user name, and going to Switch Directory. It may also be found under portal.azure.com, going to Active Directory, and Overview. Environment names may be found under https://businesscentral.dynamics.com/{tenant id}/admin.

Web Services Endpoints

Web Service endpoints include anything that has been custom exposed in Dynamics 365 Business Central. This may include KPIs, reports, individual entites, or other feeds. In Dynamics 365 Business Central, click the magnifying glass and search for Web Services to get an idea of what all are exposed by these endpoints.

Web Services Endpoint - Production

https://api.businesscentral.dynamics.com/v1.0/ODataV4/

Web Services Endpoint - Testing

https://api.businesscentral.dynamics.com/v1.0/{tenant id}/ODataV4/

Endpoint Default Changes from 2019

In the 2019 version, the default endpoint resolved to was the Web Services testing endpoint if a https://businesscentral.dynamics.com/ url was supplied to OrganizationUrl. The new default is the Common Service production endpoint. To continue using the Web Services testing endpoint, either set it directly or change the EndpointType to WSTesting.

SAP Business One

1 Connecting to SAP Business One APIs

To connect to data, specify the following:

Url: Set this to your SAP Business One Service Layer root URL.
CompanyDB: Set this to your SAP Business One company database.

2 Authenticating to SAP Business One APIs

To authenticate to SAP Business One, you must provide the User and Password connection properties.

The following are the connection properties for SAPBusinessOne. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

SAP ERP

1 Connecting to SAP ERP

Set Host, User, Password, Client, and SystemNumber. Additionally, set Language to the ISO 639-1 language code you use to log into SAP ERP. The default is "EN".

To connect to a machine different from the Host machine, set GatewayHost. The GatewayService property indicates the service on the machine; by default this is HTTP.

To connect to a distributed system or systems with other configurations:

UseSimpleNames: SAP ERP supports attribute names with special characters that many database-oriented tools do not support. You can use this property to replace any nonalphanumeric character with an underscore.
InitialValueMode: Set this to return null or the exact value returned by SAP for fields that have an undefined or unknown value. By default the provider returns null.

1.1 Connecting to a Distributed SAP System

If you are connecting to a distributed SAP system, such as a system using load balancing, you must set the following additional properties. An administrator can obtain these connection properties on the Connection tab of the System Entry Properties dialog.

· SystemId: Set this property to the value in the System Id box.

The SystemId property is the System Id or R3Name of the SAP system. The system Id is a string with a maximum of three characters.

· MessageServer: Set this property to the value in the Message Server box. If a value is specified in the SAProuter box, prepend the value in the SAProuter box onto the value for the MessageServer connection string property.

The MessageServer property must be specified when connecting to an SAP system using load balancing.

· Group: If a value is specified, set this property to the value in the Group/Server box.

The Group property specifies the logon group being used. The default in most SAP systems will be PUBLIC.

If you are using a message server service other than HTTP, set MessageServerService.

1.2 Connecting to a Custom Application Server

If you are connecting to an SAP system with a dedicated application server or a custom application server, you can obtain the following connection properties on the Connection tab of the System Entry Properties dialog.

· SystemId: Set this property to the value in the System Id box.

The SystemId property is the System Id or R3Name of the SAP system. The system Id is a string with a maximum of three characters.

· Host: Set this property to the value in the Application Server box.

The Host property specifies the host name of the target system. This value can be a regular host name, IP address, or SAProuter address.

· SystemNumber: Set this property to the value in the SystemNumber box.

The SystemNumber property defines the target system.

1.3 Configuring Secure Network Connections

If the administrator has configured Secure Network Communication (SNC), you need to set the following additional properties. You can obtain the following SNC connection string properties on the Network tab of the System Entry Properties dialog.

· SNCMode: If the "Activate Secure Network Connections" checkbox is enabled, set the SNCMode connection string property to True. If this checkbox is disabled, set the SNCMode connection property to False.

The SNCMode connection property is a boolean value determining if you are using SNC. The default value is False.

· SNCPartnerName: Set this property to the value in the SNC Name box.

The SNCPartnerName property specifies the application server's SNC name. For example: p:CN=IDS, OU=IT, O=CSW, C=DE

· SNCName: Optional. Set this property to the value in the SNC Name box.

The SNCName property specifies the name of the SNC connection. Set this property to make sure that the correct SNC name is used for the connection.

· SNCQop: Set this property to the selected option in the Secure Network Settings section. For example, if the Integrity option is selected, set the SNCQop property to 3.

· SNCLibPath: Set this property to the path and filename of your SNC library.

The SNCLibPath property specifies the full path to the security library you are using. For example, C:\Secude\secude.xll.

2 Connecting with the RFC APIs

2.1 Using the Classic RFC SDK

By default, the Classic RFC SDK without Unicode support provided with the library librfc32.dll will be used. To use it, simply place the assembly in the appRulesPortal\Bin folder.

2.2 Using the Classic RFC SDK with Unicode Support

To use the Classic RFC SDK with Unicode support provided with the library librfc32u.dll, set ConnectionType to Classic_Unicode. The following libraries from the RFC SDK must also be available at run time, in addition to librfc32u.dll:

icudt30.dll
icuin30.dll
icuuc30.dll

2.3 Using the NetWeaver RFC SDK

To use the NetWeaver RFC SDK provided with the library sapnwrfc.dll, set ConnectionType to NetWeaver. The following libraries from the RFC SDK must be available at run time, in addition to sapnwrfc.dll:

icudt30.dll
icuin30.dll
icuuc30.dll
libicudecnumber.dll
libsapucum.dll

2.4 Required RFCs

The RFCs used by the connector are listed as follows. If any listed below are not available, some or all functionality may not work. T-Code SE37 may be used to view available function modules in SAP.

DDIF_FIELDINFO_GET
RFC_GET_FUNCTION_INTERFACE
RFC_GET_STRUCTURE_DEFINITION
RFC_GET_SYSTEM_INFO
RFC_GET_UNICODE_STRUCTURE
RFC_READ_TABLE
SLDAG_CHECK_FOR_UNICODE

2.5 Filtering SAP Entities

The following connection properties provide basic functionality to select the entities you need:

TableMode: Filters tables from the DD02L system table in SAP.
QueryMode: Filters queries by your SAP workspace.
StoredProcedureFilter: Filters SAP function modules, which are modeled as stored procedures.

The following are the connection properties for SAPERP. Not all properties are required. Enter only property values pertaining to your installation. Several properties will be automatically initialized with the appRules defaults.

SAP ERP

1 Connecting to SAP ERP

Set Host, User, Password, Client, and SystemNumber. Additionally, set Language to the ISO 639-1 language code you use to log into SAP ERP. The default is "EN".

To connect to a machine different from the Host machine, set GatewayHost. The GatewayService property indicates the service on the machine; by default this is HTTP.

To connect to a distributed system or systems with other configurations:

UseSimpleNames: SAP ERP supports attribute names with special characters that many database-oriented tools do not support. You can use this property to replace any nonalphanumeric character with an underscore.
InitialValueMode: Set this to return null or the exact value returned by SAP for fields that have an undefined or unknown value. By default the provider returns null.