Month: January 2017

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

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 “How to call a custom SQL call using the Catalina API for Dynamics SL”

Using Swagger and Postman to test Catalina’s API for Dynamics SL (REST version)

Often, you don’t want to code out a client to run quick tests for an API.  Example, you might just want to retrieve a record or maybe you want to see what the return looks like when you post data to the API.  Writing a client can be a lot of work when all you need to do is just test things out.

You can do quick API calls by using Swagger and Postman.  This article is to show you how you can use Swagger to generate code so that you can then use the power of Postman to further test and work with the API. Continue reading “Using Swagger and Postman to test Catalina’s API for Dynamics SL (REST version)”

CTAPI – DEFAULTS & VALIDATIONS

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’

Introduction to CTAPI screen() Object

Most of the CTAPI Web Services are modeled after a counterpart SL client screen and intended to replicate its functionality.

The class path of these services matches the hierarchy and path to the screen in SL:

e.g.: ctDynamicsSL.financial.accountsPayable.maintenance.vendorMaintenance

screenmodel1-002

About the screen() object:

With this model in mind, all such services have a screen() object designed to match the schema of the comparable SL screen. E.g., In the Vendor Maintenance (03.270.00) SL screen, there is one SQL table referenced for reading and editing (Vendor).  This is represented by the myVendor variable of type ctDynamicsSL.Vendor inside the screen.  Also included is one read-only calculated object myBalances of type ctDynamicsSL.AP_Balances.

screenmodel2

Note: All object/table names and property/field names will match for both capitalization and naming.

Check mark.pngPro-tip: If you need to know which field to populate in the SL screen() objects, you only need to pull up Customization Mode in SL (Ctrl + Alt + C), locate the field and its name in the Property Window (F4), then find the FieldName. This FieldName correlates directly to a Table.Field and Object.Property in the screen() object.

e.g.: The following SL screen field correlates to:

ctDynamicsSL.financial.accountsPayable.maintenance.vendorMaintenance.screen.myVendor.Name

screenmodel3

In addition to the SL fields, all objects contain: public String errorMessage.

The errorMessage field defaults to a blank String “” and if populated, means that the system ran into an error during processing.

Note: when editing a screen object, any errors editing contained objects will bubble up to the screen level so it is only necessary to check the top object. 

 e.g.: if (!String.IsNullOrWhiteSpace(myScreen.errorMessage)){/*we ran into an error*/}

 Populating a screen object with defaults:

Every web service with a screen() object contains a public screen getNewscreen(screen inTemplate) call. This call will take the passed screen() object and return a copy with all default fields populated/overwritten.

Note: you can pass a null to get a completely new defaulted object.

e.g.: var myScreen = myVendorsService.getNewscreen(null);

Check mark.pngPro-tip: Some defaulted fields require other fields to be populated in order to get the right default value. E.g., CpnyID and CustID are common such fields; so it is recommend that you populate all non-defaulting fields before calling getNewscreen().

e.g.:
var myScreen = new ctDynamicsSL.financial.accountsReceivable.input.invoiceAndMemo.screen();
myScreen.myBatch = new ctDynamicsSL.financial.accountsReceivable.input.invoiceAndMemo.Batch();
myScreen.myBatch.CpnyID = “0060”;
myScreen = myIMObj.getNewscreen(myScreen); //loads defaults that depend on CpnyID

editScreen:

Every web service with a screen() object contains a public screen editScreen(String actionType, screen inScreen) call. This call is the workhouse used for Validations, Adding, Updating, or Deleting data.

The actionType parameter is standardized with:  VALIDATEONLY, ADD, UPDATE, or DELETE.

Note: you can leave actionType blank “” and the system will default to ADD if the primary keys do not already exist in the table, or UPDATE if they do. For best practices, always specify ADD or UPDATE.

e.g.:
//validate all my data before attempting to save:
var validateScreen = myVendorsService.editScreen(“VALIDATEONLY”, myScreen);
if (!String.IsNullOrWhiteSpace(validateScreen.errorMessage))
{
MessageBox.Show(“Error: ” + validateScreen.errorMessage);
return;
}

//add our new vendor entry
var add = myVendorsService.editScreen(“ADD”, myScreen);
if (!String.IsNullOrWhiteSpace(add.errorMessage))
{
MessageBox.Show(“Error: ” + add.errorMessage);
return;
}
else
{

//added our vendor, lets get the auto generated VendId
tbVendID.Text = add.myVendor.VendId.Trim();
}

//save our vendor screen updates
var update = myVendorsService.editScreen(“UPDATE”, myScreen);
if (!String.IsNullOrWhiteSpace(update.errorMessage))
{
MessageBox.Show(“Error: ” + update.errorMessage);
}
else
{
MessageBox.Show(“Save complete!”);
}

Posting Dynamics SL API examples to GitHub

Posting Dynamics SL API examples to GitHub

We are now posting our Catalina API for Dynamics SL sample client code to GitHub(under a MIT license.  Which means that you can use the sample client code for your own purposes).

I am posting the SOAP based sample clients here: https://github.com/CatalinaTechnology/ctAPIClientExamples

I just put up one for customer maintenance.  I will be posting more throughout the week (as I get them ready for consumption).  If you have any questions, feel free to Contact us.  Also, if you are a current Catalina API for Dynamics SL user and have any sample code that you would like to share with others, feel free to forward and we will see if we can get it out there for you.

Updated my larger hydroponics tower structure

Updated my larger hydroponics tower structure

I just updated our larger hydroponics tower structure (it holds 10 towers) with the same water return setup that I did the other one last week.  This looks much better and holds the towers perfectly (I hate spinning towers).  Unlike my other tower structure, where the water reservoir is below the towers, this one has the reservoir at the left side.  Because of this, I only capped the other side of the PVC post.  so that the water drains into the reservoir to the left.

List of SL Web Services in CTAPI

List of SL Web Services in CTAPI

We have been busy creating Web Services (API calls) that can simulate many of the popular screens and modules in Dynamics SL.  This makes it easier for programmers to communicate with the SL users to determine what integration points are needed.  This is also a great way to see how a user would normally use an SL screen manually.  That process can then be used a use case for the integration.

Below is a list (ever growing list) of the main screens that we have created an API equivalent to, to allow programmers, ETL (export/transform/load type software like scribe, cast iron, etc.), and apps to integrate to Dynamics SL.

If you don’t see something here, feel free to contact sales@catalinatechnology.com and we can always see about adding it. Continue reading “List of SL Web Services in CTAPI”

PH/Temp meter now in the garden

PH/Temp meter now in the garden

I finally put the sensor platform out in the garden.  I am streaming it currently on io.adafruit here: https://io.adafruit.com/bwharton/garden

NOTE:  I will be moving this stream next week to Azure.  but for now, I am using MQTT to send data to adafruit’s solution.

You can see the box that I got.  It is a bit overkill.  I also got a “power stake” so that I can easily run power to both a pump and the sensor platform.  The box is very very big.  I imagine that I will get a smaller one for future versions that I will use in marine environments. Continue reading “PH/Temp meter now in the garden”

Upgraded our Hydroponics Tower System

Upgraded our Hydroponics Tower System

We did a much needed upgrade to our hydroponics tower systems.  We replaced the rain gutter (used as a way to catch and return water to the reservoir) with a 8′ long and 5″x 5″ square PVC fence post.  This new setup is much sturdier and holds the towers exactly the way we want them (towers wont swing or turn like they did in the flimsy rain gutter).

Materials used:

One of our tower structures is 6′ long.  So, we cut the fence post to fit at 6′.  We wanted to fit 7 towers in this space, so we cut 7 evenly spaced 4.125″ square holes on one side of the post.  Applied caulk to the end-caps and placed one on each end.  Then on the “bottom” of the post, drilled a 1/2″ hole to caulk a drain pipe to dangle into the reservoir for drainage.

water-return

Now that we have this tower structure done, next step is to do our larger tower structure.

img_0369

img_0370

Cleaned up the prototype for PH sensor

wp_20170105_05_52_24_pro

I have made some changes to my PH Sensor project.  I moved it off the breadboard and did a bit of clean-up and soldered it on a perf board.  Much cleaner with screw down terminals for the external sensors.

One problem that I am having, that I have to resolve is that the probe is stuck on 2.5v.  Might be some problems with my wiring.  but it could also be the el-cheapo probe.  I’ll connect it to an Arduino and retest it outside of my project to see the results.

5165761483655009852

Here is the device in a saltwater fish pen monitoring PH to make sure the fish are in acceptable levels.

6182911483117872288

More to come.