Expiry when should the timer expire This value can be either a datetime string

Expiry when should the timer expire this value can be

This preview shows page 104 - 107 out of 307 pages.

Expiry : when should the timer expire? This value can be either a date/time string (for example 12/12/08), which will be interpreted as a specific moment, or as a Duration value, which will be interpreted as a period of time. A Duration value is expressed in the following form:
Image of page 104
4.14. DOCUMENT TYPE – PASSING FILES AS DATA 105 PnYnMnDTnHnMnS All values start with P (for Period) followed by a non-negative number of years, months, days, then T (for time), followed by a non-negative number of hours, minutes and seconds. The seconds value can have a decimal point and as many digits following the point as required (e.g. to specify fractions of a second). Any zero value parts can be omitted. Valid examples: P1Y4M3DT23H55M1.5S, P2M3D, PT10S. An example of how a variable of YTimerType appears in a dynamic form at runtime can be seen in Fig- ure 4.54. Figure 4.54: Example of a YTimerType variable rendered on a dynamic form To remove a timer from a task, select the task’s Timer property, select the ‘Never’ option in the ‘Begins’ section of the dialog, then click OK. 4.14 Document Type – passing files as data A YAWL built-in complex datatype called YDocumentType can be used to upload, store and download files of any description for a process instance. To use this feature, declare a net-level variable of YDocumentType and then map it to and from task-level variables of the same type in the usual way (cf. Section 4.7.2). At runtime, users will be able to upload and download files that will be stored as variables in the process instance (Figure 4.55). Figure 4.55: Example of a YDocumentType variable rendered on a dynamic form
Image of page 105
106 CHAPTER 4. THE EDITOR At runtime, when a process instance completes, the file can either be archived or removed from the store, de- pending on a configuration setting in the DocumentStore service (cf. Section 6.1). Note that the DocumentStore service needs to be available at runtime to support this feature (see Sections 2.4.3 & 10.1). 4.15 Custom Forms When a task is associated with the default worklist handler (i.e. the Resource Service), then at runtime the data within the task instance may be selected for viewing and/or updating. By default, the Resource Service uses a built in “dynamic forms” component, which generates appropriate but generic data editing forms designed for maximum flexibility and that can display data parameters of any type. However, their generic look and feel may not be appropriate in all cases, for example where an organisation has a standardised set of forms for their business processes, and would like their web-based forms to match that standard. In such cases, a Custom Form may be user-defined and associated with a task by specifying a URL to the form. At runtime for such a task, the Resource Service will package up the task data and send it to the custom form for display and/or editing (depending on how the form has been defined). On submission of the form by the user, the data is extracted from the form by the Service and passed back to the task in the same manner as dynamic forms. Custom forms may be built using any web-based technology, such as JSF, Javascript,
Image of page 106
Image of page 107

You've reached the end of your free preview.

Want to read all 307 pages?

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

Stuck? We have tutors online 24/7 who can help you get unstuck.
A+ icon
Ask Expert Tutors You can ask You can ask You can ask (will expire )
Answers in as fast as 15 minutes