A Tasklet Component (Bundle) is the basic building block of a job. A job can made up of one or more Tasklets. A Tasklet can be added at any position within the job chain (between two existing Tasklets, at the end of the chain, or at the beginning of the chain).
When a Bundle is added, it is assigned an ID that can never change. The name and description of the Tasklet can be edited at any time if desired. The essential building block of the Bundle, for jobs, is the Tasklet. The Tasklet is what actually gets executed when the job is run.
When adding a new component to a job, the most important settings is selecting the Tasklet Bundle from the available Bundles found in your component repository. This is at the bottom of the screen. Once selected the associated, and optional, GUI Tasklet customizer may appear (aka Weblet). The Weblet (GUI Tasklet Customizer) allows you to edit the JavaBean properties that are exposed for the given Weblet/Tasklet. Think of the Weblet as your GUI interface to configuring and editing the properties that will be used by the Tasklet when it is run within a job. The Weblet is the "design time" GUI interface to edit these properties that will be used by the Tasklet when it is run as part of a job.
The Weblet functions as the GUI interface to the Tasklet. This allows end users to configure Tasklet's properties and to use a web GUI as a user friendly interface. If the Tasklet does not have a Weblet, then an appropriate message will appear informing the user that there is no Weblet associated to this Tasklet. Again, having a Weblet GUI associated with a Tasklet is completely optional. Both the Tasklet implementation and Weblet implementation come packaged in the Bundle JAR file. Not all Bundles need or have a Weblet, but it is expected most will have one if user input is required to customize the Tasklet. Normally, a Weblet edits an input JavaBean that is passed to the Tasklet when it runs.
Once a the Bundle type is selected and saved, it can't be changed. If you wish to change it, you must delete the Tasklet and create a new one.
If the selected Tasklet has a Weblet it will be displayed at the bottom of the screen. The Weblet will normally allow the user to edit the properties of the input JavaBean associated with the Tasklet. The Weblet can also perform other functions like accessing local or remote web services using the UniversalClient API. Weblets will normally save any associated input JavaBeans to a persistent store that is provided by the supporting JobServer Container as provided by the SOAFaces specification.
When a Tasklet is disabled, it will not be executed when the job is run. It will essentially be skipped over.
The error dependency settings control how the job proceeds with its execution if the Tasklet produces certain kinds of errors. This is often needed when the job is made up of multiple Tasklets. You can decide if a job continues to run or stops completely if certain errors occur during Tasklet processing.
If the Tasklet has an input and/or output JavaBean, the user has the option of saving the input and/or output JavaBean when the Job is run. This allows the Job to log exactly what inputs the Tasklet used when it ran and what outputs it generated during its job processing. This is a very powerful auditing tool for the user. Using this, the user can view exactly how the Job was run and under what conditions (inputs and outputs). The input/output JavaBean can be viewed using the Job Tracker tool. There is an optional GWT GUI interface called the RuntimeViewer that are associated with a Bundle, that if implemented allow the user to visualize the input and output JavaBeans used during every job run the Tasklet ran within.
This allows the user to configure if a Tasklet will wait for all background java threads, created in the Tasklet, before it exits. Normally, if the main java thread used by a Tasklet completes, the Tasklet will get marked as completed. However, if the Tasklet starts secondary/background threads, this property can allow the Tasklet to decide if it should wait on all background threads or not, before marking the Tasklet as complete. You can typically leave this set to "No" unless your Tasklet requires special handling.
Leaving the list blank will allow the Weblet and RuntimeViewer, using the UniversalClient GWT API,
to call any Mule endpoint they wishes. You can restrict the Weblet to access
only certain Mule endpoints by listing them out. If you do not want the Weblet
to have access to any Mule endpoints, then enter a fake endpoint like
vm://xyz, for example.
The Mule related features will only be available if your JobServer environment has the Mule package included in the JobServer installation. If Mule is not enabled in your JobServer environment, you will not see the related Mule features.