The rest_v2/jobs service provides the interface to schedule reports and manage scheduled reports (also called jobs). This service provides an API to scheduler features such as bulk updates, pausing jobs, FTP output and exclusion calendars.
This chapter includes the following sections:
| • | Listing Report Jobs |
| • | Extended Job Search |
| • | Viewing a Job Definition |
| • | Defining the Job Trigger |
| • | Scheduling a Report |
| • | Viewing Job Status |
| • | Editing a Job Definition |
| • | Updating Jobs in Bulk |
| • | Pausing Jobs |
| • | Resuming Jobs |
| • | Restarting Failed Jobs |
| • | Deleting Jobs |
| • | Specifying FTP Output |
| • | Specifying File System Output |
| • | Storing Additional Job Parameters |
Listing Report Jobs
Use the following method to list jobs, either all scheduled jobs on the server or the jobs for a specific report:
| Method | URL | ||
| GET | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs?<argument> | ||
| Argument | Type/Value | Description | |
| reportUnitURI? | /path/to/report | Optional URI (repository path) of a report or report option to list all of its jobs. You may need to encode the / characters in the URI with %2F. When specified, the results are only for the given report or report option. | |
| Options | |||
| accept: application/xml accept: application/json | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The body contains and array or list of jobsummary descriptors. | 404 Not Found – When no job is found. | ||
For example, if your application wants to request all the jobs for a given report, it would send the following URL (%2F is the / character):
In the response from the server, The jobs are described in a jobsummary element such as the following example:
| | The jobsummary XML element returned by the rest_v2/jobs service has a different structure than the element with the same name returned by the deprecated rest/jobsummary (v1) service. |
Extended Job Search
The GET method is also used for more advanced job searches. You can search by owner or for strings in the label, or you can match arbitrary fields of the job descriptor with a special syntax. You can also control the pagination and sorting order of the reply.
| Method | URL | ||
| GET | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs?<arguments> | ||
| Argument | Type/Value | Description | |
| label | string | Performs a case-insensitive string search for this value anywhere within the label field of every job. | |
| owner | string | The name of the user who scheduled the report, if necessary in the format <username>%7C<organization> (%7C is the | character). | |
| reportUnitURI? | /path/to/report | Specify the URI of a report or report option to list all of its jobs. You may need to encode the / characters in the URI with %2F. | |
| example? | JSON jobModel | Searches for jobs that match the JSON jobModel, which is a fragment of a job descriptor containing one or more fields to be matched. Because the JSON fragment appears as an argument to the URL, it must be properly URL-encoded (percent-encoded). See the example below. | |
| limit | integer | Turns on pagination of the result by specifying the number of jobsummary descriptors per results page. The default is -1 for no limit and thus no pagination (all results are returned together). | |
| offset | integer | Determines the page number in paginated results by specifying the index of the first jobsummary to be returned. | |
| sortType |
| Possible values are: NONE, SORTBY_JOBID, SORTBY_JOBNAME, SORTBY_REPORTURI, SORTBY_REPORTNAME, SORTBY_REPORTFOLDER, SORTBY_OWNER, SORTBY_STATUS, SORTBY_LASTRUN, SORTBY_NEXTRUN | |
| isAscending | true / false | Determines the sort order: ascending if true, descending if false or omitted. | |
| Options | |||
| accept: application/xml accept: application/json | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The body contains and array or list of jobsummary descriptors that match the search criteria. | 404 Not Found – When no matching job is found in the server. | ||
The body of the response contains jobsummary elements, in the same format as shown in Listing Report Jobs.
The example parameter lets you specify a search on fields in the job descriptor, such as output formats. You can specify any field in the job descriptor or in any of its nested structures. Some fields may be specified in both the example parameter and in a dedicated parameter, for example label. In that case, the search specified in the example parameter takes precedence.
For example, you can search for all jobs that specify an output format of PDF. The JSON jobModel to specify this field is:
{"outputFormat":"PDF"}
And the corresponding URI, with proper encoding, is:
http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs?example=
%7b%22outputFormat%22%3a%22PDF%22%7d
Viewing a Job Definition
Once you search for and find the ID of a job, use the GET method with that specific job ID to retrieve its detailed information.
| Method | URL | ||
| GET | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/<jobID>/ | ||
| Options | |||
| accept: application/job+xml accept: application/job+json | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The body contains a descriptor with all details about the job. | 404 Not Found – When the specified job is not found in the server. | ||
The GET method returns a descriptor that fully describes all the aspects of a scheduled job, such as recurrence, parameters, output, email notifications, and alerts, if any. All fields are included, many of which may be null if not set for the chosen job. For additional options around file output, see Specifying FTP Output and Specifying File System Output.
JSON:
XML:
Defining the Job Trigger
Within the descriptor of the job, the trigger determines when it will run. A trigger is said to fire when it reaches its scheduled time, and when it does, the server generates the report associated with the job. There are two kinds of triggers:
| • | simpleTrigger - Simple recurrence that fires a given number of times with a given interval in between. |
| • | calendarTrigger - Calendar recurrence that fires at specific times on given days of the week or days of the month. |
The following sections give the fields that define each trigger and when they fire.
Simple Trigger
The simpleTrigger has the following fields to define its recurrence pattern:
| Field and JSON Example | Description |
|---|---|
| timezone | The timezone for all dates and times used by the trigger. |
| startType | Determines when the job becomes active. For the simple trigger, this also determines the base time at which recurrence starts. Supported values: 1 - The job starts immediately, and the trigger fires right away. 2 - The job starts at the startDate, at which time it will fire. |
| startDate | The date and time at which the job will start. The simple trigger will fire at this time, and it will begin its recurrence at this time. The format is "yyyy-MM-dd HH:mm" and the timezone field is applied. |
| endDate | The date and time at which the job will stop. The trigger will not fire after this time, even if any occurrences still remain, unless a misfire occurs and the misfire policy allows it. The format is "yyyy-MM-dd HH:mm" and the timezone field is applied. Note that using T as a separator in the endDate is not supported. |
| calendarName | The name of a previously defined exclusion calendar. An exclusion calendar defines a set of dates or times when the job will not run, for example a list of holidays. You can update the exclusion calendar without changing the job. For information about creating and modifying exclusion calendars, see The calendars Service. |
| misfireInstruction | An integer value that defines the behavior if the trigger did not fire when scheduled. A misfire occurs if JasperReports Server or its Quartz scheduler component is offline when a trigger was supposed to happen and run a job. It can also occur if all threads of the scheduler are busy and the job cannot run when the trigger should fire. When the scheduler restarts or a thread becomes available again, it checks for any triggers did not fire on time. In this case, the scheduler takes action based on the value in this field. The misfire instruction does not apply if the trigger fires normally but the report encounters an error. The values are described in the next table. |
| occurrenceCount | An integer that defines how many times the trigger will fire, provided the recurrence intervals happen before the endDate. |
| recurrenceInterval | The time interval between scheduled firings of the trigger. The interval unit is provided in the next field. |
| recurrenceIntervalUnit | The unit of time for the recurrence interval. Supported values: MINUTE, HOUR, DAY, WEEK. For units greater than MINUTE, the startType and startDate is the basis for recurrence. For example, if the trigger runs immediately and recurs every 2 days, it will run at the current time on the subsequent days. |
Choose a misfire policy based on how frequently your job runs and how critical it is. For example, an outage may last one to two hours, and if a daily report is critical, you may want it to run as soon as the scheduler is able. However, if a report runs every hour, you may want to ignore missed reports and wait for the next report at the scheduled time. Note that different policies may have the same effect depending on how the trigger is defined, but also the same policy may have different effects on different trigger types.
| misfireInstruction | Description for Simple Triggers |
|---|---|
| 0 | No instruction (same behavior as option -1 below). Does not trigger the job that misfired, and takes no action. Because the trigger did not fire, the number of occurrences is not decremented. This is the default behavior if no misfireInstruction is defined. The trigger will fire the next time according to the recurrence value and unit, as if the misfire had fired at the proper time. |
| -1 | Ignore misfire policy. Instructs the scheduler that the trigger will never be evaluated for a misfire situation, and that the scheduler will simply try to fire it as soon as it can, and then update the trigger as if it had fired at the proper time. This value has the same effect as 0: take no action and do not change the number of occurrences. |
| -999 | Called the smart policy. Instructs the scheduler that upon a misfire situation, the custom updateAfterMisfire method will be called on the trigger to determine the misfire action. In this case, you must define and enable a custom trigger class on the server, which is beyond the scope of this documentation. |
| 1 | Run now: instructs the scheduler to trigger now, which is the time the misfire is detected. If the outage covers several trigger times, they will each have a misfire, and with this value, they will each run now. |
| 2 | Instructs the scheduler that upon a misfire situation, the SimpleTrigger will be re-scheduled to 'now' (even if the associated calendar excludes 'now') with the repeat count left as-is. This does obey the trigger end-time, so if 'now' is after the end-time, the trigger will not fire. |
| 3 | Instructs the scheduler that upon a misfire situation, the SimpleTrigger will be re-scheduled to 'now' (even if the associated Calendar excludes 'now') with the repeat count set to what it would be, if it had not missed any firings. This does obey the trigger end-time, so if 'now' is after the end-time the Trigger will not fire. |
| 4 | Ignores any missed firings of the trigger (no action is taken for the missed firing), but the repeat count is set to what it would be if the trigger had fired normally. The trigger will fire at the next scheduled time after the current time, taking into account any associated exclusion calendar or end time. The effect is that missed trigger occurrences will be skipped. |
| 5 | Ignores any missed firings of the trigger (no action is taken for the missed firing), but the repeat count is left unchanged. The trigger will fire at the next scheduled time after the current time, taking into account any associated exclusion calendar or end time. The effect is that missed trigger occurrences will happen later, past the last expected occurrence. |
Calendar Trigger
A calendar trigger lets you schedule a job to run multiple times based on any combination of time and date. The various fields let you define single values, ranges, or wild-cards for minutes, hours, days, weeks, or months. For example, you can run a report every 15 minutes from 10am to noon every Monday.
| Field and JSON Example | Description | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| timezone | The timezone for all dates and times used by the trigger. | ||||||||||||
| startType | Determines when the job becomes active. Supported values: 1 - The job starts immediately, and the trigger may fire right away. 2 - The job is scheduled to start at the specified start date. | ||||||||||||
| startDate | The date and time at which the job will be active. The trigger will not fire before this time; it will only fire for calendar occurrences that happen after this time. The format is "yyyy-MM-dd HH:mm" and the timezone field is applied. | ||||||||||||
| endDate | The date and time at which the job will stop. The trigger will not fire after this time, unless a misfire occurs and the misfire policy allows it. The format is "yyyy-MM-dd HH:mm" and the timezone field is applied. Note that using T as a separator in the endDate is not supported. | ||||||||||||
| calendarName | The name of a previously defined exclusion calendar. An exclusion calendar defines a set of dates or times when job will not run, for example a list of holidays. You can update the exclusion calendar without changing the job. For information about creating and modifying exclusion calendars, see The calendars Service. | ||||||||||||
| misfireInstruction | An integer value that defines the behavior if the trigger did not fire when scheduled. A misfire occurs if JasperReports Server or its Quartz scheduler component is offline when a trigger was supposed to happen and run a job. It can also occur if all threads of the scheduler are busy and the job cannot run when the trigger should fire. When the scheduler restarts or a thread becomes available again, it checks for any triggers did not fire on time. In this case, the scheduler takes action based on the value in this field. The misfire instruction does not apply if the trigger fires normally but the report encounters an error. The values are described in the next table. | ||||||||||||
| minutes | Specifies the minute or minutes at which the trigger fires. The value can consist of the following tokens:
| ||||||||||||
| hours "hours":"8-16"
| Specifies the hour or hours at which the trigger fires. The minutes field determines when during the hour that the trigger will fire, possibly multiple times. All hours are specified in 24-hour format. The value can consist of the following tokens:
| ||||||||||||
| months "months": {"month": ["3", "6", "9", "12"]}
| A list of months during which the trigger fires. The month values are 1 for January and 12 for Dececmber. | ||||||||||||
| daysType "daysType":"WEEK"
| Determines whether trigger days are defined by week or by month, or both. Supported values: ALL, WEEK, MONTH | ||||||||||||
| weekDays "weekDays": {"day": ["1", "4", "6"]}
| Specifies a list of days of the week on which the trigger fires. The hours and minutes fields determine when during the day the trigger will fire, possibly multiple times. The day values are 1 for Sunday and 7 for Saturday. | ||||||||||||
| monthDays "monthDays": "1,3,5-22"
| Specifies the days of the month on which the trigger fires. The hours and minutes fields determine when during the day the trigger will fire, possibly multiple times. The value can consist of the following tokens:
|
For example, the following calendar trigger should run at 3:30 AM every Monday in every month.
Choose a misfire policy based on how frequently your job runs and how critical it is. For example, an outage may last one to two hours, and if a daily report is critical, you may want it to run as soon as the scheduler is able. However, if a report runs every hour, you may want to ignore missed reports and wait for the next report at the scheduled time. Note that different policies may have the same effect depending on how the trigger is defined, but also the same policy may have different effects on different trigger types.
| misfireInstruction | Description for Calendar Triggers |
|---|---|
| 0 | No instruction (same behavior as option -1 below). Does not trigger the job that misfired, and takes no action. This is the default behavior if no misfireInstruction is defined. The trigger will fire the next time according to the times and days that were defined. |
| -1 | Ignore misfire policy. Instructs the scheduler that the trigger will never be evaluated for a misfire situation, and that the scheduler will simply try to fire it as soon as it can, and then update the trigger as if it had fired at the proper time. This value has the same effect as 0: take no action and wait for the next calendar trigger. |
| -999 | Called the smart policy. Instructs the scheduler that upon a misfire situation, the custom updateAfterMisfire method will be called on the trigger to determine the misfire action. In this case, you must define and enable a custom trigger class on the server, which is beyond the scope of this documentation. |
| 1 | Run now: instructs the scheduler to trigger now, which is the time the misfire is detected. If the outage covers several trigger times, they will each have a misfire, and with this value, they will each run now. |
| 2 | Ignores any missed firings of the trigger (no action is taken for the missed firing), but updates the trigger to fire at the next scheduled time after now, taking into account any associated exclusion calendar or end time. The effect is that missed trigger occurrences will be skipped. |
Scheduling a Report
To schedule a report, create its job descriptor and use the PUT method of the jobs service. Specify the report being scheduled inside the job descriptor.
| Method | URL | ||
| PUT | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/ | ||
| Content-Type | Content | ||
| application/job+xml application/job+json | A well-formed XML or JSON job descriptor as described below. | ||
| Options | |||
| accept: application/job+xml accept: application/job+json | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 201 Created – The body contains the job descriptor of the newly created job. It is similar to the one that was sent but now contains the jobID for the new job. | 404 Not Found – When the report specified in the job descriptor is not found in the server. | ||
When you schedule a report, create a job descriptor similar to the one returned by the GET method. However, you need only specify the relevant fields in the job descriptor; do not include any null fields. Do not specify any job IDs in the descriptor, because the server will assign them. For example in JSON:
If needed, you can configure the server to accept the other parameters and keep them with the newly create job, but the default is to only store the required fields. For more information, see Storing Additional Job Parameters.
The response of the PUT request is the descriptor of the newly created job, similar to the result of the GET request shown in Viewing a Job Definition. It includes all the fields of the job descriptor, including the server-assigned ID and all the null fields.
Viewing Job Status
The following method returns the current run time state of a job:
| Method | URL | ||
| GET | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/<jobID>/state/ | ||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – Body contains the status descriptor. | 404 Not Found – When the specified <jobID> does not exist. | ||
Editing a Job Definition
The POST method replaces the entire definition of a job with a new descriptor. To modify an existing job definition, use the GET method to read its job descriptor, modify the descriptor as required, then use the POST method of the jobs service.
| Method | URL | ||
| POST | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/<jobID>/ | ||
| Content-Type | Content | ||
| application/job+xml application/job+json | A well-formed XML or JSON job descriptor. The request can include either a complete descriptor such as the result of a GET request described in Viewing a Job Definition, or it can be a minimally sufficient descriptor as shown in Scheduling a Report. | ||
| Options | |||
| accept: application/job+xml accept: application/job+json | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The response include the complete job descriptor, for an example, see Viewing a Job Definition. | 404 Not Found – When the specified <jobID> does not exist. | ||
Updating Jobs in Bulk
The POST method also supports other parameters to perform bulk updates on scheduled jobs.
| Method | URL | ||
| POST | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs?<arguments> | ||
| Argument | Type/Value | Description | |
| id? | jobID string | Can be used multiple times to create a list of job IDs to update. | |
| replace | true / false | Specify true when you send a new trigger type. By default, this is false, and the trigger can be updated but not changed to a different type. See below. | |
| Content-Type | Content | ||
| application/json application/xml | A well-formed jobModel descriptor, which is a fragment of a job descriptor containing only the fields to be updated. See example below. | ||
| Options | |||
| accept: application/json accept: application/xml | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The array or list of jobs that were restarted. | 404 Not Found – When the specified <jobID> does not exist. | ||
In this usage, the POST method allows you to send a partial job description, called a jobModel, that contains any subset of the job descriptor's fields. This update applies to one or more jobs whose ID is specified by the id argument. For example, the following simple request will update the job description in several jobs:
However, the jobModel provides two mechanisms to create complex updates:
| • | You can describe nested structures by using the nestedNameModel equivalent element. Like the jobModel, nested model elements contain only the subset that you want to modify. Thus you could change one value within a parameter, the end date within a schedule, or an email address within a notification. |
| • | You can remove the definition of an element by using the isElementNameModified element and giving it the value true. This indicates that the element's new value is null, and thus that the element should be removed altogether from the job descriptor. |
In the following example, the description will be removed from the target jobs, and their triggers will be modified. Note that XML descriptors do not use the trigger element and thus do not have a triggerModel element:
The response has an array or list of jobId elements that were updated:
JSON: {"jobId":[8321,8322]}XML: <jobIdList> <jobId>8321</jobId> <jobId>8322</jobId> </jobIdList>[/code] |
Pausing Jobs
The following method pauses currently scheduled job execution. Pausing keeps the job schedule and all other details but prevents the job from running. It does not delete the job.
| Method | URL | ||
| POST | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/pause/ | ||
| Content-Type | Content | ||
| application/xml application/json | An array or list of job IDs to pause. See example below. If the body of the request is empty, or the list is empty, all jobs in the scheduler will be paused. | ||
| Options | |||
| accept: application/json accept: application/xml | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The array or list of jobs that were paused. Jobs specified with a <jobID> that doesn't exist are ignored without error. |
| ||
The request and the response have the same format, an array or list of jobId elements:
JSON: {"jobId":[1236,1237,1238,1239]}XML: <jobIdList> <jobId>1236</jobId> <jobId>1237</jobId> <jobId>1238</jobId> <jobId>1239</jobId> </jobIdList>[/code] |
Resuming Jobs
Use the following method to resume any or all paused jobs in the scheduler. Resuming a job means that any defined trigger in the schedule that occurs after the time it is resumed will cause the report to run again. Missed schedule triggers that occur before the job is resumed are never run.
| Method | URL | ||
| POST | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/resume/ | ||
| Content-Type | Content | ||
| application/xml application/json | An array or list of job IDs to resume. See example below. If the body of the request is empty, or the list is empty, all paused jobs in the scheduler will resume. | ||
| Options | |||
| accept: application/json accept: application/xml | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The array or list of jobs that were resumed. Jobs specified with a <jobID> that doesn't exist are ignored without error. |
| ||
The request and the response have the same format, an array or list of jobId elements:
JSON: {"jobId":[1236,1237]}XML: <jobIdList> <jobId>1236</jobId> <jobId>1237</jobId> </jobIdList>[/code] |
Restarting Failed Jobs
Use the following method to rerun failed jobs in the scheduler. For each job to be restarted, the scheduler creates an immediate single-run copy of job, to replace the one that failed. Therefore, all jobs listed in the request body will run once immediately after issuing this command. The single-run copies have a misfire policy set so that they do not trigger any further failures (MISFIRE_ INSTRUCTION_IGNORE_MISFIRE_POLICY). If the single-run copies fail themselves, no further attempts are made automatically.
| Method | URL | ||
| POST | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/restart/ | ||
| Content-Type | Content | ||
| application/xml application/json | An array or list of job IDs to restart. See example below. | ||
| Options | |||
| accept: application/json accept: application/xml | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The array or list of jobs that were restarted. |
| ||
The request and the response have the same array or list of jobId elements:
JSON: {"jobId":[8321,8322]}XML: <jobIdList> <jobId>8321</jobId> <jobId>8322</jobId> </jobIdList>[/code] |
Deleting Jobs
Use the DELETE method to remove jobs from the scheduler. There are two forms to specify a single job or multiple jobs to delete.
| Method | URL | ||
| DELETE | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs/<jobID>/ | ||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The body contains the ID of the deleted job. | 404 Not Found – When the specified job is not found in the server. | ||
| Method | URL | ||
| DELETE | http://<host>:<port>/jasperserver[-pro]/rest_v2/jobs?<arguments> | ||
| Argument | Type/Value | Description | |
| id | Multiple String | Enter as many job IDs as you want to delete, for example: ?id=5594&id=5645&id=5761 | |
| Options | |||
| accept: application/xml accept: application/json | |||
| Return Value on Success | Typical Return Values on Failure | ||
| 200 OK – The content is a list of deleted jobs, as shown in the example below. |
| ||
The list of deleted jobs in the response has an array or list of jobId elements:
JSON: {"jobId":[5594,5645,5761]}XML: <jobIdList> <jobId>5594</jobId> <jobId>5645</jobId> <jobId>5761</jobId> </jobIdList>[/code] |
Specifying FTP Output
The REST service allows a job to specify output to remote files through FTP (File Transfer Protocol). In addition to the repository location, you can specify an FTP server and path where JasperReports Server will write the output files when the job runs. You also need to provide a username and password to access the FTP server.
To specify these parameters, add the outputFTPInfo element to the XML job descriptor, as shown in the following example:
FTP output is always specified in addition to repository output, and the output will be written to both the repository and the FTP location. You cannot specify FTP output alone. The file names to be written are the same ones that are generated by the job output, as specified by the baseOutputFilename, sequential pattern if any, and format extensions such as .pdf. Similarly, the file overwrite and sequential filename behavior specified for repository output also apply to FTP output.
FTP output also supports SSH private keys stored in the repository for authentication. All of the fields for the outputFTPInfo element are described in the following table:
| Field | Description | JSON Example | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| type | Type of FTP connection requested: ftp (default), ftps, or sftp. | "type": "sftp" | ||||||||||||
| serverName | The host name of the FTP server. | "serverName": "ftp.example.com" | ||||||||||||
| port | Integer value that specifies the port number of the ftp server. The default value depends on the connection type: ftp = 21, sftp = 22, and ftps = 990. | "port": 22 | ||||||||||||
| userName | The login user name for the FTP server. | "userName": "anonymous" | ||||||||||||
| password | The login password for the given userName on the FTP server. | "password": "securePassword" | ||||||||||||
| folderPath | The path of the folder where the job output resources should be created. | "folderPath": "/path/to/folder" | ||||||||||||
| implicit | Specifies the security mode for FTPS, Implicit if true (default) or Explicit if false. If implicit is true, the default port is set to 990. | "implicit": false | ||||||||||||
| protocol | Specifies the secure socket protocol to be used, for example SSL or TLS. | "protocol": "TLS" | ||||||||||||
| prot | Specifies the PROT command for FTP. Supported values:
| "prot": "C" | ||||||||||||
| pbsz | Specifies the protection buffer size: 0 to (2^32)-1 decimal integer. The default is 0. | "pbsz": 0 | ||||||||||||
| sshKey | Repository URI of the SSH private key resource (used for SFTP authentication). | "sshKey": "/sshKeys/myOpenSSHKey" | ||||||||||||
| sshPassphrase | The passphrase for the SSH private key (used for SFTP authentication). | "sshPassphrase": "mySecurePhrase" |
Administrators can store SSH key files in the repository by right-clicking a folder and selecting Add Resource > File > Secure File from the context menu. For more information, see the JasperReports Server Administrator Guide.
Specifying File System Output
When configured, you can also specify a path on the local file system to write job output. The user running the server process must have write permission in that location.
In order for file system output to work, the server must be properly configured. In the file .../WEB-INF/applicationContext.xml, you must set the enableSaveToHostFS property to true. As described in the configuration chapter of the JasperReports Server Administrator Guide, this setting also enables file system output from the scheduler user interface for all users, which could be a security risk.
To create a job with file system output, add the outputLocalFolder element to the XML job descriptor, as shown in the following example:
As with FTP output, file system output is always specified in addition to repository output, and the output will be written to both the repository and the local folder. The file names to be written are the same ones that are generated by the job output, as specified by the baseOutputFilename, sequential pattern if any, and format extensions such as .pdf. Similarly, the file overwrite and sequential filename behavior specified for repository output also apply to file system output.
Storing Additional Job Parameters
When sending a job descriptor as described in Scheduling a Report, the server does not store all fields in the descriptor, only the ones needed to define the job. If you wish to keep any additional parameters in the newly created job, you can configure the server so that all valid job fields submitted to the jobs service are stored.
Locate the following file and modify the configuration bean. After saving the new configuration, you must restart the server for the change to take effect.
| Storing Additional Job Parameters | ||
| Configuration File | ||
| .../WEB-INF/applicationContext-cascade.xml | ||
| Bean | Description | |
| allowExtraReportParameters | The default value is false, and only essential job parameters are stored when creating a job. When set to true, all valid job descriptor parameters sent when creating the job are stored in the newly created job. | |
Recommended Comments
There are no comments to display.