Syntax

RedwoodScript provides three syntax options:

The first two are abbreviated syntax that allow you to dispense with all or most of the boiler plate code that is normally required to write RedwoodScript code that interacts with SAP CPS. The boiler plate includes all the declarations you would usually have to make yourself.

The Short mode automatically generates everything, including import statements for classes that you are most likely to use in your task. This mode is activated if the first symbol is {.

The Short with imports mode allows you to specify the imports. In this case there are no automatic imports, and you will have to specify all the imports you need. This mode is activated if the first symbol is import.

The Full mode lets you write the entire Java class. This mode is activated if the first symbol is package. In full mode you will have to explicitly extend the stub that is provided for you. This will be done automatically in all other modes.

The following illustrates the use of the short syntax for a Hello World! program:

{

jcsOut.println("Hello, World!");

}

The following illustrates the "Hello, World" example when it is fully expanded into RedwoodScript:

package com.redwood.scheduler.custom;

import java.math.BigDecimal;

import java.util.Iterator;

import com.redwood.scheduler.api.date.DateTimeZone;

import com.redwood.scheduler.api.model.*;

import com.redwood.scheduler.api.model.enumeration.*;

public class name

extends nameStub

{

public void execute()

throws Exception

{

jcsOut.println("Hello, World");

}

// ... Lots of code ...

}

As you can see there is quite a considerable amount of code generated for you. The only difference between the short and short with imports is that in short mode, all the imports are specified for you, and in short with imports mode you must specify all required imports yourself.

Redwood API

In most contexts, frequently used Redwood API classes are imported by default, the imported classes and objects are visible in the Stub code.

You can find information about objects and their types in apidocs.zip, which is provided when you have purchased the Chargeable version. If you extract this, and open apidocs/index.html you will be taken to the main index of the API documentation.

The main index consists of two sections:

Please look at each of the links in the Scheduler API and Language Reference at the bottom of the page carefully, they contain the answers to many frequently asked questions.

The Data model shows you the available tables in the database for use with RedwoodScript, see the Querying the database section below for examples of how to query the database with RedwoodScript.

Object Model

Repository objects have types, for example:

The type of the object determines the methods you can call.

You call methods on an instance of an object. The available methods are documented in the API documentation.

You can get repository objects from a predefined object called the jcsSession which is an instance of SchedulerSession in the API documentation:

[...]

JobDefinition jobDefinition = jcsSession.getJobDefinitionByName("System_Info");

[...]

Once you have an object, you use methods to get information from it, or to manipulate it.

[...]

jcsOut.println(jobDefinition.getName());

[...]

Submitting a job

{

//Get the job definition

JobDefinition jobdef=jcsSession.getJobDefinitionByName("System_Info");

//Create the Job

Job infoJob=jobdef.prepare();

//Get the Queue

Queue SystemQ=jcsSession.getQueueByName("System");

//Attach queue to job

infoJob.setQueue(SystemQ);

//Print out the jobid of the job

jcsOut.println(infoJob.getJobId());

//Submit the job

jcsSession.persist();

}

More documentation is available in the API documentation and on the Internet, RedwoodScript being a java-like language, there are a lot of Java resources online, remember that you must look at Java 1.4, as 1.5 and 1.6 implement a lot of shorthands which are not available in SAP CPS.

Querying the Database

You cannot query the tables in the database directly, only an upper-layer table-implementation; the available tables in SAP CPS are listed in the API documentation. The Data model and can be found under the Scheduler API and Language Reference section on the index page.

The database can be queried with the following function, which is defined in the SchedulerSession object:

executeQuery(query string, [[bind variables])

Standard SQL can be used in queries, however, when referring to a column, you need to prepend the table name, which name is the type of the object you want to query for, followed by a period (.), as shown below;

jcsSession.executeQuery("select Job.JobId,Job.Description from Job", null, dest);

The output can be generated in HTML (for output on screen), CSV (comma separated values, for spreadsheet applications) and XML. For this you need to define a Reporter and ReportDestination; both require their own classes. The code below illustrates how to create a Reporter, a ReportDestination; and how to use a query for the report.

import com.redwood.scheduler.api.model.report.Reporter;

import com.redwood.scheduler.api.model.report.ReportDestination;

{

String query = "select Job.JobId,Job.Description from Job where Job.JobId <= 244";

Reporter reporter = jcsSession.createReporter(jcsOut);

ReportDestination dest = reporter.getCSVReportDestination();

jcsSession.executeQuery(query, null, dest);

}

The same example as above using bind variables:

import com.redwood.scheduler.api.model.report.Reporter;

import com.redwood.scheduler.api.model.report.ReportDestination;

{

String query = "select Job.JobId,Job.Description from Job where Job.JobId <= ?";

Reporter reporter = jcsSession.createReporter(jcsOut);

ReportDestination dest = reporter.getCSVReportDestination();

jcsSession.executeQuery(query, new Object[] { new Long(244L) }, dest);

}

Bind variables can increase the performance and scalability of queries, especially simple queries, like the one above. Some supported databases, like Oracle, parse every query once and skip some queries they have already parsed. So if the Job.JobId above changes frequently, the database will have to parse each and every query for each Job.JobId, if we use a bind variable, this step can be skipped.

The following example is for illustration purposes, when you do not know the job status code and want to use it in a query (note that looking up the code is easier). You have to import the JobStatus class, the fully qualified class name can be found in the API documentation:

import com.redwood.scheduler.api.model.enumeration.JobStatus;

import com.redwood.scheduler.api.model.report.Reporter;

import com.redwood.scheduler.api.model.report.ReportDestination;

{

String query = "select Job.JobId,Job.Description from Job where Job.Status = ?";

Reporter reporter = jcsSession.createReporter(jcsOut);

ReportDestination dest = reporter.getCSVReportDestination();

jcsSession.executeQuery(query, new Object[] { String.valueOf(JobStatus.ScheduledCode) }, dest);

}

Comparing Timestamps

Dates or timestamps in the repository are stored as a combination of an offset since 'the start of time' and a timezone. The start of time (also known as the epoch) is the number of milliseconds since midnight, Jan 1st 1970 UTC.

To compare dates in queries, a SQL function named TODATE can be used:

The following code illustrates comparing two dates:

import com.redwood.scheduler.api.model.report.Reporter;

import com.redwood.scheduler.api.model.report.ReportDestination;

{

Reporter reporter = jcsSession.createReporter(jcsOut);

ReportDestination dest = reporter.getCSVReportDestination();

jcsSession.executeQuery("select JobId from Job where CreationTime > TODATE('2009-09-01', 'CET', 'yyyy-MM-dd')", null, dest);

}

Using RedwoodScript in Objects