Unleashing the Power of the Axeda Platform via Scripto
The Axeda Platform allows developers to extend the functionality of their M2M applications using a Groovy Custom Object, but that’s only part of the solution to building a connected app. The remaining piece is invoking this extra functionality and including the output where needed. That's where Scripto comes in.
What is Scripto?
While other Web Services might offer only a Domain Specific Language, Scripto is unique in providing adaptable Domain Specific Services.
In the context of a Web Service, the Domain Specific Language or Domain Specific Services act as an intermediary between the application and the web service.
A typical web service constrains the developer's freedom to format the data in the way most appropriate to the application in favor of the schema provided by the Domain Specific Language.
In contrast, with the Axeda Platform the developer creates the app as the entry point and the Custom Object as the endpoint for the data, enjoying complete control over how the data is processed from start to finish. Scripto as the broker allows the data to pass between the two points via a simple POST request. Scripto doesn’t require special attention as the intermediary, whereas a typical Web Service fails unless the data conforms to the schema of its domain specific language.
To see Scripto in action, let’s take as an example a javascript function that uses an XMLHttpRequest to send a parameter via an Http POST to Scripto.
The updatepage callback function can be as simple as desired:
function updatepage(str) {
document.getElementById("result").innerHTML = str;
}
This function accesses a web service and embeds the results in a web page. A call to Scripto makes it easy.
Integration Services is an entire industry. The standard practice is to write balky clients and adapters to an existing set of Web Services. Sometimes this means multiple distributed teams developing custom services and consumers at the same time. The integration that Scripto provides solves a real problem when building rich solutions.
Static vs. Dynamic Services
Domains and Data Models can be very different from system to system. Using static SOAP or REST services encourages tight coupling. The “dynamic” services provided by Scripto enable systems to share a common Domain Language.
Scripto provides developers freedom to leverage their existing XML or JSON schemas and model their domain, rather than model their problem in another domain.
The Advantages of Scripto:
• Supports Parameterized Input
• Every tuple is passed to your Script
• Customizable Output
• Custom Content-type
• RESTful
• Uses HTTP as its transport
Consuming Scripto as a RESTful Service
As a RESTful service, Scripto is resource-based rather than operation based. REST specifies the “how” not the “what,” allowing the service to be truly agnostic of content type. Scripto is called with a RESTful url such as the following:
http://dev6.axeda.com/services/v1/rest/Scripto/execute/MyCustomObjectName
or more generically:
http://host:port/services/v1/rest/Scripto/execute/CustomObject
Scripto supports both GET and POST:
• GET = Parameter values passed in the Query String
• POST = Parameter values passed in the Body
Authentication information may be session token-based, or passed inline in the URL:
https://dev6.axeda.com/services/v1/rest/Scripto/execute/MyCustomObjectName? username=thisuser&password=thispassword&thisparameter=thisvalue
Logging from Scripto
The Logger is injected into every Groovy Script.
Standard log4j syntax:
• logger.info(“Here’s info”)
• logger.warn(“Warning’s here”)
• logger.error(“ERROR. ERROR. ”)
• logger.debug(“Alas there is no debug”)
The logger is well suited to debugging running scripts, but it’s not the only option for Scripto.
Custom Response Handling
By giving control of the response back to the developer, Scripto enables precise error handling.
• Use an outer try/catch to control unexpected behavior
• Return from the Script at any point in the code
• Return anything from a StackTrace to a custom error code.
The Axeda Platform SDK
The Context instantiates the custom object and permits it access to other SDK resources.
com.axeda.drm.sdk.Context
The Context mechanism enforces privileges when performing SDK operations.
By calling “Context.create()” the custom object returns a user-based context for which privileges have already been granted within the Platform.
The Finder Pattern
com.axeda.drm.sdk.core.Finder
The Finder Pattern is implemented by classes that search for and return collections of entities from persistent storage. Using the “findAll()” method, a list of all data may be returned that matches the specified criteria, or an empty list if none. The number of records returned may be restricted based on system configuration.
// Find all devices of a given model
public List findDevicesByModel(Context context, Model model)
{
// Instantiate the DeviceFinder
DeviceFinder deviceFinder = new DeviceFinder(context); // Additional mutator of DeviceFinder implementation to restrict
// search by model
deviceFinder.setModel(model); // Perform the actual search
return deviceFinder.findAll();
}
Modeling a domain on the Platform works well with assets, which are perfect for physical OR virtual entities. Expression Rules represent the rules of a system. For everything else, there are Extended Objects.
Extended Objects:
• User-defined Objects on the System
• Objects are collections of typed name/value pairs called “Properties”
• The ExtendedObject search API enables searching on Property values using
"and","or","not", "like“, <,>,>=,<=,==,!=
Domain Specific Services drastically reduce the obstacles to integration, and dynamic development is rapid development. Modeling a Domain with Extended Objects, Expression Rules and Scripto Services enables more flexible and cohesive systems. To learn more about Scripto services on the Axeda Platform, check out these related resources
- Building a "HelloWorld" WebService with Scripto
- HTML, AJAX, and Scripto Tutorial
- Scripto Example: Retrieve an asset-uploaded file
