Posts
To script a component in TDI (SDI) you start with the basic Script version of that component. So in order to script a Connector, you add a Script Connector.
Typing 'script' in the Search box filter the selection list. Since we'll be implementing only Iterator mode, we may as well choose this mode in the wizard.
Our new Connector looks pretty much like any other Connector at this point. All the features provided by the TDI AL framework are visible in the various tabs: Input/Output Map, Hooks, Delta, Connection Errors and Pool. You can also choose the Mode and State for your Connector, as well as when the component will initialize. Only the Connection tab is specific to the technology our Connector is interfacing with. That is why this aspect is called the Connector Interface, or CI for short.
The Connection tab of our Script Connector does not hold the usual set of parameter (yet), but instead gives us access to the interface logic of the component via the Edit Script... button.
Press this button to open the script editor.
Once in the editor, we can see that our new Connector has a preloaded example script. At the top are the two functions necessary for Iterator mode: selectEntries() and getNextEntry().
This is how a scripted component works: if the required functions are present in the script, then that operation or mode is available. Note however that for a scripted Connector, the Mode drop-down will always contain all modes - including those not supported by its script.
Iterator mode selects its data set with selectEntries() and then iterates through it using getNextEntry() to return one Entry at a time and to signal End-of-data when the data set is exhausted. Here is the standard template for these function with a little comment added for clarity:
var counter = 0;
function selectEntries()
{
// initialize the 'data set'
counter = 0;
}
function getNextEntry ()
{
// if the data set is exhausted, setStatus to 0
if (counter > 100) {
result.setStatus (0);
// This next line is no longer required after TDI 7.1
result.setMessage ("End of input");
return;
}
// otherwise, populate the conn Entry via the 'entry' variable
entry.setAttribute ("counter", counter);
counter++;
// setStatus is 1 by default, which means 'more data available'
}
A scripted Iterator is easy to test in the Schema section of the Connector's Input or Output Map. Pressing the Connect button calls the initialize() function (if one exists), followed by querySchema()and then selectEntries().
The reason information shows up under Schema when you press the Connect button is because there is a template script for querySchema(). Here is a copy of it with clarifying comments:
function querySchema ()
{
// the 'list' variable is a Java Vector for returning
// one or more schema items. Each one is added to the
// Vector as an Entry with two attributes:
// name - the name of the attribute
// syntax - a string value with guidance to the developer
var e = new com.ibm.di.entry.Entry();
e.addAttributeValue("name","counter");
e.addAttributeValue("syntax","Number");
list.add(e);
// once again, setStatus to 1 means info available
result.setStatus (1);
}
If there is no querySchema() function then the Schema grid is first populated when you start stepping through the data set. You will also note that there is no way to signal if a schema item is Required or not. This is schema item option only available if you code your component using Java. However, I have been creative with what I put in the Syntax value and have not missed this feature :)
Once connection and selection are complete then the Connect button is grayed and the Next button becomes available. Each time you press this button it results in a call to getNextEntry() and either returns data or signals EOD.
And now for something cool: Simply open the script editor again and change the If-statement in getNextEntry() to signal EOD after 10 entries instead of 100. Then return to the Input Map tab, press the Close button in the Schema area and then Connect again. This causes the script to be reprocessed and lets you test any changes you made to the code immediately.
Ok, enough theory for now. Let's strip out all the template functions except for selectEntries() and getNextEntry() which we will be rewriting. In addition, we will add the initialize() function as well as some global variables. Here's what the start of the script looks like:
// MyRestConnector
vrs = 0.9; // 20161117 created this component
// main.logmsg() provides info in the Console view in the CE
// You could also write to stdout: java.lang.System.out.println(...)
main.logmsg("MyRestConnector v." + vrs);
// All variables defined outside of function bodies
// are global for the entire script.
//
// Here is the HTTP Client Connector we'll use to make requests
// Discovering what the 'internal name' of a Connector is requires a little legwork,
// and I'll get back to this in a later post.
// Discovering what the 'internal name' of a Connector is requires a little legwork,
// and I'll get back to this in a later post.
var http = system.getConnector("ibmdi.HTTPClient");
// Hardcoding the URL for now. Later we'll create a Connection Form
var url = "http://www.ideal-status.nl/static/consumer_notification_advice.json";
// Variables for our NodeList and index
var nodeList = null;
var nodeIndex = 0;
function initialize()
{
// Initialize the HTTP Client CI loaded above
http.initialize(null);
// Reset the data set
nodeList = null;
nodeIndex = 0;
}
We can test the validity of this script by bringing up the Input Map tab again and pressing Connect. If you did not empty out the selectEntries() function then you'll get an error when you try this.
Now we come to the meat of our Connector: selectEntries(). This function does most of the work of component, setting up and making the REST request, parsing the JSON payload received and then preparing the data set to be returned by subsequent calls to getNextEntry(). These three steps are called out in the comments included in the code below:
function selectEntries()
{
// PREPARE REQUEST
// Set up an Entry for passing Output attributes that
// control parameter settings
var requestEntry = system.newEntry();
requestEntry["http.url"] = url;
requestEntry["http.Accept"] = "application/json";
// The HTTP method is GET by default, but just in case...
requestEntry["http.Method"] = "GET";
// Make the request and store the response in a local Entry
// Note that the queryReply() method is what CallReply mode uses
var responseEntry = http.queryReply(requestEntry);
// Check the responseCode returned by the service
var responseCode = responseEntry.getString("http.responseCode");
// If this is not a 2xx return, then throw an exception
if (!responseCode.startsWith("2")) {
var responseMsg = responseEntry.getString("http.responseMsg");
throw "Error making request: " + responseCode
+ " - " + responseMsg;
}
// PARSE JSON RECEIVED
// Wrapping this in try-catch for better error handling
try {
var json = responseEntry.getString("http.bodyAsString");
// fromJSON() is a static method, so we can call it via the class
var hEntry = com.ibm.di.entry.Entry.fromJSON(json);
} catch (ex) {
throw "Error parsing JSON return: " + ex
+ "\nJSON: " + json;
}
// PREPARE DATA SET
nodeList = hEntry.getChildNodes();
nodeIndex = 0;
}
Once again we can test that our script so far is correct (at least syntactically) by using the Close and Connect buttons. We are still not seeing any data returned yet because that's the responsibility of getNextEntry() which we code to look like this:
function getNextEntry ()
{
// If the data set is exhausted, setStatus to 0
if (nodeIndex >= nodeList.getLength()) {
result.setStatus (0);
return;
}
// Otherwise, populate the conn Entry via the 'entry' variable
// Borrowing this code from the AL made in the previous blog
// First grab the next node and increment the index
item = nodeList[nodeIndex];
nodeIndex++;
// The 'entry' variable is the conn Entry for this Connector
entry.id = item.getName();
var children = item.getChildNodes(); // get next level
for (var child in children) {
// set conn attribute using child att name and value
entry[child.getName()] = child.getValue();
}
// For completeness sake, I like to set the return status
result.setStatus(1);
}
Once this is in place then we can start testing it using the Close, Connect and Next buttons.
And what's more, if we drop our Connector into an AL then we can step through the script in the AL Debugger.
Each time you press the ENTER key then the script snippet is passed to the running server and run in the context of where the AL processing is at that point. This lets you inspect the state of your component by logging the results of all statements executed, as shown in the screenshot above. Furthermore, you can modify the values of variables and attributes, as well as the contents of Entry objects. You can also define new variables and instantiate new objects, calling scripted functions and invoking Java methods as desired.
I'll keep my love ballad to the AL Debugger short and conclude with the recommendation that you learn to love this time-saving tool.
And I'll wrap up another extended blog here. But I will return to show you how to set up the custom Connection tab for your scripted Connector, so stay tuned!
