How to Custom Call Stored Procedures with REST that have Customizable XML Parameters

Many of Catalina Technology’s stored procedures accept a field called @parms that is an XML field for configurable parameters to be passed. An example of this is below.

You can see that there is a parameter getting passed called “@parms”. In that is a XML string that contains one or more parameter. In this case, there is a single parameter called “ADDRID” and it is getting passed the value of “C%” so that it can return all addresses that start with a “C”

exec xct_spDSLGetAddresses @currentPageNumber=N'0',@pageSize=N'500',
@parms=N'<nameValuePairs>
    <key name="ADDRID" value="C%"/>
</nameValuePairs>'

To call this RESTfully, you need to HTML escape the XML string so that things like double quotes (“) will not cause the JSON to break.

Below is an example of how we would call the custom stored procedure above, but call it through the Catalina RESTful API.

curl --location --request POST 'http://YOURSERVER/ctDynamicsSL/api/customSQL/xct_spDSLGetAddresses' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Basic YOURAUTH' \
--header 'SiteID: YOURSITEID' \
--header 'CpnyID: YOURCPNYID' \
--data-raw '{ 
    "parameters": 
    [
        { 
        "name": "currentPageNumber", "value": "0"
        },
        { 
        "name": "pageSize", "value": "0"
        },
        { 
        "name": "parms", "value": "<nameValuePairs><key name=\"ADDRID\" value=\"C%\"/></nameValuePairs>"
        } 
    ]
}'

Catalina XML Configuration File Editor: ctConfigEditor

ctConfigEditor is the stand-alone executable used to create and edit the custom XML documents used to configure our full line of web services. Our xml structure supports storing sql connection data and a range of name/value pairs. All data is easily encryptable for added security.

Step 1:

Choose whether you are editing an existing file or creating a new config file from scratch. If loading an existing config file, you will need to fill in your catalina software license key as well as your sitekey.

Step 2:

Either load an existing Site ID or create a new Site ID.
You can identify which Site ID you are editing on all screens at the top of the screen where it says, “Currently Editing: SiteID“. If this value is blank, it means you are creating a new SiteID entry.
Note: TO DEFAULT ALL KEYS: Load an existing Site ID, then enter a New Site ID and hit the “Create Site” button.

Step 3:

Set your Database connection strings. Both the .NET format and OLE String format.
.NET Format:  user id=USERNAMEHERE;password=PASSWORDHERE;database=DATABASENAMEHERE;server=SERVERNAMEHERE
OLE Format:  Provider=SQLOLEDB;User Id=USERNAMEHERE;Password=PASSWORDHERE;Initial Catalog=DATABASENAMEHERE;Data Source=SERVERNAMEHERE
For more information on sql connection strings and other options available, we recommend reading at: http://www.connectionstrings.com/

Step 4:

Edit the config options available or create custom entries. Note: you can optionally encrypt any field by just checking the “encrypt” checkbox next to a key. We recommend only encrypting sensitive data.

Step 5:

On the “Finish” tab you will see the option to Preview the XML file or Save it to a file. Click the appropriate button.
You can optionally change your siteKey/encryptKey by filling in the new key in the SiteKey text field. Note: You will need to remember to update any client applications to use the new siteKey.


Access Catalina’s API for Dynamics SL using .NET Core

If you are looking to build a cross platform application in .NET Core that can access Dynamics SL, you can use Catalina’s API for Dynamics SL. This is a demo on how you can do it using Visual Studio and deploy the client to Windows, Mac, and/or Linux (or any OS that supports .NET Core).

Demo on Connecting to Dynamics SL through .NET Core

You can get the source code for this demo on our GitHub site: https://github.com/CatalinaTechnology/dotNETCore/MyConsoleApp


Retrieve Catalina Queue FIFO

If you use the Catalina Queue Engine for queuing records, you might want to retrieve data in a FIFO (First In First Out) method. This means you want to grab the oldest records first. This is easily accomplished by calling the Catalina Queue API with the parameter sortBy in the query string.

Example, if you are retrieving the queue ORDERS, you would format your URL, for the Queue API, like this:

http://YOURSERVER/ctDynamicsSL/api/queue/ORDER?sortBy=createdDate

This will then sort the queue in Ascending order by createdDate. Which means it will retrieve oldest items first.

Below is a curl example that does the same thing.

curl -X GET \
'http://YourServer/ctDynamicsSL/api/queue/QUEUETYPE?sortBy=createdDate' \
-H 'Accept: application/json' \
-H 'Authorization: Basic YOURAUTHHERE' \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-H 'CpnyID: YOURCPNYID' \
-H 'SiteID: YOURSITEID' \
-H 'cache-control: no-cache'

Minimum SQL Security Requirements for Catalina API

Minimum:
db_datawriter
db_datareader
db_ddladmin

If you are going to use our userMaintenance web service, to manage SL user logins, it will also need:
db_securityadmin
db_accessadmin

Also note that by default, we normally install our scripts under the dbo schema. So, you also have to give the user, we are connecting as, execute on that schema.

eg. grant  execute on schema :: [dbo] to usernamehere



Catalina’s Queue Engine

Catalina has a simple queuing engine that allows you to track changes on any table in SQL server. There is then an API that allows you to retrieve items that have been queued so that you can take action on them.  This is mostly done when you need to send Dynamics SL data, that has changed, to an outside system.

Example: A customer in Dynamics SL is modified in the SL Customer Maintenance Screen. You want to make sure that the customer terms, class, and other information makes it out to Salesforce.com (or other CRM system). Continue Reading


How to call a custom SQL call using the Catalina API for Dynamics SL

How many times have you wanted to just make a SQL call from an app, website, or other system, but you don’t have direct access to a SQL connection or other easy method to call SQL?

Well the Catalina API for Dynamics SL has a secure way for you to make SQL calls over to your SL database using the Catalina common.asmx web service call.

Below is a quick tutorial on how to do this using .NET and the Catalina API for Dynamics SL (SOAP calls) Continue Reading


CTAPI – DEFAULTS & VALIDATIONS

Catalina Technologies API for Dynamics SL allows you to create your own custom defaults and validations when sending data into SL through the API.

How to set Custom Defaults and Validations for web services in CTAPI. As of RELEASE builds post 2017/1/1, you are now able to overwrite defaults and validations in two single files. This is now the preferred place to make customizations, as it will avoid overwriting changes with new release builds of CTAPI.

The file for Defaults customizations is named: custom.default.ctDynamicsSL.xml and is located in your DEFAULTCONFIGDIRECTORY. (Path defined in your DSLCONFIGFILE, default: c:\inetpub\xctFiles\config\)
The file for Validations customizations is named: custom.validate.ctDynamicsSL.xml and is located in your VALIDATIONCONFIGDIRECTORY. (Path defined in your DSLCONFIGFILE, default: c:\inetpub\xctFiles\config\)
All customizations for defaults and validations for all CTAPI web services are contained in these two files.
Definition of the custom.default.ctDynamicsSL.xml file:

capture1

ID: (The field to set)
1. inItem – Always used to represent the Table/Object being defaulted. (not the field)
DEFAULTTYPE: (TEXT, PROC, CODE)
1. TEXT – sets the field value to the value listed in this xml element.
2 PROC – sets the field value to the value returned by the stored procedure listed in the xml element value. (optional: PARMS attribute listing stored procedure parameters)
3. CODE – sets the field value to the value returned by performing an eval on the code listed in the xml element value.

PARMS: (An optional, comma-delimitated list of parameters used for PROC Type defaults)
1. Variables from the inItem object that match stored procedure variable names.
e.g.: PARMS=’inItem.Status’
2. Rename an inItem object variable to a different stored procedure variable name.
e.g.: PARMS=’VendStatus=inItem.Status’
3. Hardcoded Stored procedure variable values.
e.g.: PARMS=’Active=1’

Definition of the custom.validate.ctDynamicsSL.xml file:

capture2

ID: (The field to set)
1. inItem – Always used to represent the Table/Object being defaulted. (not the field)
VALIDATETYPE: (LIST, PROC, NUMBERRANGE, DATERANGE, CODE)
1. LIST – a comma delimitated list of text values that are valid.
2. PROC – validates based on returnValue returned by the stored procedure listed in the xml element value. (optional: PARMS attribute listing stored procedure parameters)
3. NUMBERRANGE – a comma delimitated range of doubles.
e.g.: 1,5
4. DATERANGE – a comma delimitated range of dates.
e.g.: 1/1/2016,1/1/2019
5. CODE – validates the Boolean returned by performing an eval on the code listed in the xml element value.

PARMS: (An optional, comma-delimitated list of parameters used for PROC Type validations)
6. Variables from the inItem object that match stored procedure variable names.
e.g.: PARMS=’inItem.Status’
7. Rename an inItem object variable to a different stored procedure variable name.
e.g.: PARMS=’VendStatus=inItem.Status’
8. Hardcoded Stored procedure variable values.
e.g.: PARMS=’Active=1’