Skip navigation
All People > banty01 > Tyler Band's Blog > 2018 > September

CA Live API Creator 5.0 introduced a new service that allows developers to extend their connectivity to outside data sources using a new framework.  This framework is a collection of JavaScript code which can access Java JAR files and execute the basic operations of configuring, connecting, retrieval, update, and manipulation of external datasets.  The 5.0 release ships with 2 examples, MongoDB (a NoSQL database) and JDBCExample (an Apache/Derby sample).  


The Extensible Data Source Framework is accessed using the 'Data Sources' Add button on a new or existing API.  To add a new Data Source Provider (you will need to logon to the 'sa' account to see the wizard) you can start the process of cloning an existing example or creating one from scratch.  Depending on the datasource, you will need to add one or more JAR files to your container classpath and restart your server.  The examples show how to reference the Java classes using the Java.type('') syntax.  Once you have created a test connection, configuration, and configuration info (the parameters used and passed to your connection).  You will need to retrieve a minimal set of metadata to describe the objects (enitites), attributes (if available), and datatypes (e.g. string, number, boolean, etc). Some datasources do not have this information which is okay (see the MongoDB getMetadata example). 


If your needs are limited to read-only (e.g. GET) then you will need to implement the getQuery and getOne code. The query code will have access to the rest sysfilter and sysorder variables.  The getOne code is used to retrieve an object by primary key(s).  The getInsert, getUpdate, and getDelete code sections can be skipped if this will be a read-only provider.  If the database does not support transactions, then the commit and rollback sections can also be skipped.  Finally, the close connection is only needed if you are passing a shared connection between calls (e.g. poolable connection). For more details, see the documentation page. 


CA Live API Creator (LAC) uses REST to manage all aspects of creating, updating, and managing APIs.  Over the past few years, the team created a series of command line utilities to support the management and devops lifecycle of a running a LAC server.  The command line tools fell into two camps (lacadmin and lac) both written in NodeJS. The 'lacadmin' is used to manage internal API objects.  The 'lac' is a generic REST utility for GET, PUT, POST,  DELETE and a few other fun features. 


The installation and packaging for these command line tools have been used by devops to create scripts to handle migrations, deployments, testing, and maintenance.   A new GitHub project called liveapicreator-devops takes the NodeJS services and compiles them into executable files for windows, linux, and macos. This means the sample scripts that use the lacadmin or lac can be run without the need to install NodeJS or NPM (node package manager).  Simply copy the lacadmin and lac compiled packages to your global path and your devops can run scripts anywhere on that platform machine. (Note: you may need to grant execute/read permissions for linux or macos). 


Sample Scripts

The sample-scripts directory has 2 sub-directories.  One is a devops sample on how to promote your LAC APIs from dev to production.  The basic scripts show how to list all your APIs components (a sort-of report writer) or how to list your meta data about a datasource.   Once you have copied your lacadmin and lac to your global path - these scripts should work using the Single-User Developer version (aka Jetty Package). 

CA Live API Creator has evolved over the many years.  In the 5.0 release, one of the biggest changes is the elimination of the admin SQL database.  It is not really gone, it has been replaced by an in-memory Java/Derby database and the source is now written to the a system repository.  During the 4.1 release, a new ZIP file format was introduced that created fine-grain JSON, JavaScript, SQL, and HTML object types.  These objects were ready to be checked into a source control system (SCS).  In 5.0, this ZIP format is now the standard for the file based repository.  


The recipe for migration can be very simple.  Just export your current API (aka project) as a JSON file and import his into 5.0.  Of course there are plenty of details to talk about (datasource passwords, custom authentication providers, libraries, gateway interfaces, and managed data servers) but the migration requires that each of the these components be exported from the source server and then imported into the new 5.0 target server.


The LAC team wrote a simple utility to help customers with the migration recipe. This utility can be found on the GitHub site (see MigrationService).  The migration service is a Java program that connects to the source LAC and generates a shell or command script.  The export script is the recipe for finding all the correct objects and saving to disk.  The import script will reverse the process and create these object on the new 5.0 running LAC server.  The script attempts to solve many of the user issues faced during a migration and may not address every condition. 


There are new features to explore in LAC 5.0 (see the releaseNotes) and enjoy the power of LAC.