GB2559999A

GB2559999A - Generic customizable navigation workflow and reporting systems for capturing mobile forms data

Info

Publication number: GB2559999A
Application number: GB1702991.9A
Authority: GB
Inventors: Fai Lau Kwun
Original assignee: Individual
Current assignee: Individual
Priority date: 2017-02-22
Filing date: 2017-02-24
Publication date: 2018-08-29
Also published as: GB201702991D0

Abstract

A method of report management in a workflow system comprises a user defining a desired level of quality and associated risk, as well as how to deliver data to an external device 104, e.g. a transaction log, to achieve the desired quality. This may involve specifying a policy of optimistic or pessimistic locking. A request is received from an online business transaction form 101 to perform an operation on a data bucket 102. It is determined that more than one type of policy information is applicable to the data bucket and any differences between these are resolved. An external device is coupled to the data bucket via a data pipe 103 and the requested operation is performed according to the user defined information relating to how to achieve the desired quality. The method may be used for capturing mobile forms data, which may be transferred to the coupled external device in a hierarchical structure.

Description

(56) Documents Cited:

None (32) 22.02.2017 (33) US (58) Field of Search:

Other: No search performed: Section 17(5)(b) (71) Applicant(s):

Kwun Fai Lau

Rm G. 20/F, Block 6, On Ning Garden, Tseung Kwan O, Hong Kong, China (72) Inventor(s):

Kwun Fai Lau (74) Agent and/or Address for Service:

Geoffrey Dal I i more

The Whitehouse, 17 Brunswick Hill, Reading, RG1 7YT, United Kingdom (54) Title of the Invention: Generic customizable navigation workflow and reporting systems for capturing mobile forms data

Abstract Title: Specifying policies relating to reporting of data to an external device (57) A method of report management in a workflow system comprises a user defining a desired level of quality and associated risk, as well as how to deliver data to an external device 104, e.g. a transaction log, to achieve the desired quality. This may involve specifying a policy of optimistic or pessimistic locking. A request is received from an online business transaction form 101 to perform an operation on a data bucket 102. It is determined that more than one type of policy information is applicable to the data bucket and any differences between these are resolved. An external device is coupled to the data bucket via a data pipe 103 and the requested operation is performed according to the user defined information relating to how to achieve the desired quality. The method may be used for capturing mobile forms data, which may be transferred to the coupled external device in a hierarchical structure.

105 Middleware
	102 Bucket

	103 Data Pipe

FIG, 1

104

Device

1/4


	-1 J,OX Form

2/4

20.1,., Destqn form and

202 Execute data collection

.....

204 Couple external device via a pipe rib. Z

3/4

ΐκ Sff........ ^xy

Γ^ 1 v *s Λ

I***#*- -StajP

4/4

GENERIC CUSTOMIZABLE NAVIGATION WORKFLOW AND REPORTING

SYSTEMS FOR CAPTURING MOBILE FORMS DATA

FIELD OF THE INVENTION [001] This invention is generally related to workflow automation. Specifically, this invention relates to data reporting.

BACKGROUND OF THE INVENTION [002] A mobile data collection workflow typically generates reports by coupling with external devices that assume a relational database schema design. Transaction logs, access logs, audit logs, analytical analysis are some of the more common types of reports that are frequently used.

[003] FIG. 1 illustrates such a system, here a mobile survey workflow, in accordance with the prior art. A data collection form 101 issues a request, such as a PUT ora POST request, typically through an online API, to workflow middleware 105. Workflow middleware 105 then performs an operation in accordance with the request. Subsequently, the workflow middleware publishes the request and the processed result to a bucket destined for a next step in the workflow. The workflow middleware may also issue an event notification through event API to data pipe (aka data bus) 103. Thus operations on events are held by the data pipe 103. Fora data collection survey such operations are likely to include PUTS and POSTS, but for a userinteractive application such operations may include update, insert and delete requests.

[004] Each operation will, at some point in time, be written by the data pipe 103 through the data API to coupled device (e.g. transaction log) 104. When a commit associated with a set of operations (a transaction) is finally confirmed as having been forced to the device, all operations from one or more forms comprising the transactions are also included and the workflow middleware can guarantee that it is possible to establish an aggregated state of the workflow for the device to be consistent with. In otherwords, whilst the data pipe is permitted a degree of flexibility about pending execution of the operations comprising a transaction, all such operations must be published to device by the time of the commit. At this point, the data pipe resumes processing of incoming events from workflow middleware 105. Note, incoming requests from online forms to workflow middleware do not get interrupted and continues while the workflow middleware sending operations comprising a transaction to a data pipe.

[005] Forcing data to coupled device is however an expensive process, in terms of time and processing power. The idea of an asynchronous commit is therefore known; this means that as far as a form and the middleware is concerned, its request has happened, but in reality the data pipe may force or defer appropriate data to coupled device at a later time. An option is thus provided such that under certain circumstances if the data pipe is asked to force a commit of operations, such forcing is not immediately but is done asynchronously. It is also commonly known that a lazy write system can have a write flush performed once every second to improve performance for write intensive operations. Asynchronous forcing can however result in consistency problems. If the data pipe fails prior to a force, it is not then possible to be sure of the state of the coupled device. It is also possible for the requirements for forcing data to coupled device to be relaxed. For example a transaction may be designated as 'semi-persistent_. This means that upon controlled shutdown, the data pipe guarantees not to lose data but does not make the same guarantees upon system failure.

[006] All of the above solutions are however predefined by the workflow middleware designer. Form designers are not provided with any flexibility. There may be certain circumstances under which a form designer is prepared to accept a particular degree of risk which is appropriate to the kind of environment that they are operating in; e.g., pessimistic locking may be sacrificed for speed.

SUMMARY OF THE INVENTION [007] One embodiment provides a method enabling a form designer to specify policy information for use by a data pipe a mobile workflow data collection system, where the policy determines how to deliver information relating to a data bucket to coupled devices (aka data set) so as to achieve a desired level of report quality standard. A form designer is able to specify at least two measurable objectives to be associated with information to be delivered, a first measurable objective being specifiable fora first system state and a second measurable objective being specifiable fora second system state, the measurable objectives being interpretable by the data pipe to determine a delivery behavior necessary to conform with the policy information.

[008] In a preferred embodiment, a form designer is permitted to specify one or more measurable objectives to be associated with information to be delivered. Preferably at least one measurable objective is that business rules should be maintained for a set of operations on one or more data buckets having such a measurable objective associated therewith.

[009] In one embodiment the data pipe is a reporting layer and the information relating to an event is a message. In this embodiment it is possible for a user to specify reporting requirements for an event dependent upon a system operational state' e.g. at most once _ delivery whilst the system is at state A and exactly once _ delivery whilst the system is at state B. Some examples of operational states may include but not limited to: bucket size, pipe size, bucket transfer rate, pipe transfer rate, and administrator chosen runtime expression that is extensible to support reporting requirements that are not known at time of survey workflow design and initialization. Preferably a user is able to specify the interaction between two types of policy information, both being applicable to the same information.

[0010] In a second embodiment, a data pipe delivers data to one or more coupled devices upon receiving a request to deliver information relating to a data bucket. Policy information is processed to determine howto deliver the information so as achieve a desired level of report quality standard. The policy information specifying a first measurable objective specifiable for a first system state and a second measurable objective specifiable fora second system state, interpreting measurable objectives in order to determine a delivery behavior necessary to conform with the policy information, and delivering the information relating to the data bucket accordingly. In a preferred embodiment it is possible to determine that more than one type of policy information is applicable to the data bucket to be reported on, in which case differences are preferably resolved to determine what delivery behavior is appropriate.

[0011] In another embodiment, a form designer is able to specify policy information for a workflow middleware for use by a data pipe in determining how to deliver information relating to a data bucket so as to achieve a desired level of report quality standard. The form designer is able to specify at least two measurable objectives to be associated with information to be reported on. A first measurable objective is specifiable fora first system state and a second measurable objective is optionally specifiable fora second system state. The measurable objectives being interpreted by the data pipe to determine a delivery behavior necessary to conform with the policy information.

[0012] In yet another embodiment, a data pipe delivers data information relating to a data bucket aggregating information. A reading component exists to read policy information in order to determine howto deliver the information so as achieve a desired level of report quality standard. The policy information specifies a first measurable objective fora first system state and a second measurable objective fora second system state. An interpreting component exists for interpreting measurable objectives in order to determine a delivery behavior necessary to conform with the policy information. Another delivery component exists for delivering the information relating to the data bucket accordingly.

BRIEF DESCRIPTION OF THE DRAWINGS [0013] FIG. 1 shows a workflow middleware in accordance with a preferred embodiment.

[0014] FIG. 2 shows a flowchart of coupling device via data pipe to a running data collection workflow to support changing reporting requirements.

[0015]FIG. 3 shows a flowchart of processing of the present invention in accordance with a preferred embodiment.

[0016] FIG. 4.shows a flowchart of determining of delivery measurable objective and reporting requirement.

DETAILED DESCRIPTION OF THE INVENTION [0017] FIG. 1. It is not always desirable to achieve adequate performance by synchronous use of such a device due to the frequently significant cost of interaction by a workflow data collection middleware with a coupled external device. Best transactional delivery even in the event of failure causes inherently high runtime expense. This is true in, for example, a system in which new inserts of form data into data buckets are short-lived and the throughput is high, such as a mobile survey workflow. There are known design techniques for transactional program designers to make tradeoffs between optimistic locking and pessimistic locking. There is a risk that entire (but not partial) transactions may be lost in the case of failures. Nevertheless, depending on the type of data being processed by the system, this is a risk that a designer may be willing to accept in order to improve the throughput of the system.

[0018] In interactive online systems today, form designers can request various qualities of service, including various levels of data transfer and synchronization. For example, optimistic locking control can be defined at runtime so that persistent system state will not be lost, although non-persistent ones may be. Optimistic locking control is defined so that all operations within a transaction will atomically succeed or fail. The meaning of such qualities of service is however pre-defined.

[0019] The emphasis is typically on the provision of near real-time report data availability. However, there are also more low value micro-transactions being processed in between logical checkpoints. Form designers might well choose to take a calculated risk in failure and certain other cases. Thus in accordance with the preferred embodiment, a form designer is permitted to define various levels of report quality standard in the event of operational states.

[0020] Operational states could be defined as data transfer rate, amount of data, and so on. Other operational states could also be defined such as business rules driven. Further, in certain circumstances operational states may inherit properties from other operational states. For example, a plurality of items (columns of certain tables) that when accesses in combination may expose unauthorized information. An attempt to access certain quantities of information during a given period of time (e.g. in one request) may be considered unauthorized by some business rules associated with a data pipe and couple device, even if the associated bucket access rates have not been exceeded. Other operations states may be a system chosen checkpoint or an administrator chosen runtime expression that is extensible to support reporting requirements that are not known at time of survey workflow design and initialization. Thus the system is provided with a reasonable degree of flexibility.

[0021] FIG. 2 illustrates a flowchart of coupling device via data pipe to a running data collection workflow to support changing reporting requirements. Online survey form 201 has the ability to associate policy information 206 with an operation; operation type; or transaction and this policy information is then used by the middleware to determine how the middleware reports requests from the forms which relate to a particular operation. Such policy information is preferably defined by a system administrator during system setup. Such defined policies are then preferably exposed to either forms or workflow steps for their use. A policy may refer to a particular operation, a operation type, ora particular transaction. A policy may also be associated with a step in a workflow.

[0022] FIG. 3 is a flowchart of the processing of the present invention in accordance with a preferred embodiment. At step 301, survey form issues a request such as to PUT into a bucket 302 associated with the workflow middleware. The request is received by the workflow middleware and a policy for the data being PUT is determined 302. The policy may be based on policy information obtained from policy information at the same time as step 301. If a policy is obtained from policy information, information regarding the policy is preferably delivered with the request. Thus when the request is received at step 302, an appropriate processing policy can be retrieved from the request itself.

[0023] Policy information may also be associated with a particular workflow step, which is preferably specified by the workflows administrator at design time. However, it is possible fora workflows administrator to specify an overriding policy. For example, an administrator may decide that a particular reporting policy is appropriate irrespective of the policy specified atforms. This decision could be based on the workflow administrator's knowledge of the purpose of the step in question.

[0024] Alternatively, policy information could be derived from the data of a business rule. For example, a business rule which increases the level of report quality standard for operations of higher business-defined value. Such business rule information is preferably held in buckets 302 but is defined at data pipe. Once the bucket 303 has determined the policy that will be applied to the operation, that operation is put to data pipe with an indication of the policy that should be applied by a data pipe. Data pipe 304 determines how and when to deliver to a coupled device in order to ensure conformance with the appropriate policy.

[0025] The data pipe preferably has knowledge of possible reporting requirements (policy choices) for an operation or transaction and knows what is necessary to achieve such requirements in terms of delivery behavior. Thus in order to ensure that a workflow event is delivered, pessimistic locking may be used to cover the situation. However, in order to ensure that a system failure does not cause a workflow event not to be delivered or to be delivered more than once, optimistic locking may be used to handle the form s requests. Thus delivery behavior necessary to achieve a particular reporting requirement may vary dependent upon the system's operational state. F urther a user may wish to specify a different reporting requirement for each possible operational state. The data pipe permits an administrator to define different reporting requirements for each of the possible operational states, and uses the knowledge to determine the overall behavior required to achieve the reporting requirement specified for each operational state. Policy information and extensible business rules may refer to the individual operational states and desired reporting requirements for each of those states. Policies are defined at data pipe but exposed for use by form designers and workflow designers.

[0026] In a preferred embodiment, two policies are defined by the user (i.e., the administrator or form designer, rather than the middleware or system designer) for Pessimistic Locking, and Optimistic Locking. For each policy, the administrator is able to define a reporting requirement for each of the three operational states of the middleware. In order to guarantee delivery, a pessimistic locking may be used irrespective of the operational state. An administrator may, of course, create additional policies and fill in their details as required. Data pipe may use the knowledge it holds and the information provided by the administrator regarding reporting requirements, to determine the appropriate delivery behavior for each policy (e.g., to complete the logging behavior). Such an approach allows a very flexible system where the delivery behavior may be determined at system setup or may be determined dynamically at runtime. The former is a less processor intensive approach and is therefore preferable.

[0027] FIG. 4 is a flowchart illustrating the processing of the data pipe in accordance with a preferred embodiment. A policy definition excludes the delivery behavior, and the middleware determines the delivery behavior for each operational state that is necessary to achieve the overall reporting requirement specified for each operational state 401. The result of 401 is used to combine with any reporting requirement at each bucket to determine an aggregated policy at individual buckets 402. Any delivery requirement for individual external device is combined with requirement of an associated bucket to determine an overall delivery behavior appropriate for the policy 405. The administrator is provided with a great deal of flexibility. Each data bucket is associated with an external device via a data pipe resolves to a report quality level (policy). This is provided as an attribute of the data pipe. When a workflow event or data is put or inserted into the device for the first time, the report quality level is provided to the data pipe in accordance with defined policy information.

[0028] Policy information could be specified by a system administrator or alternatively be defined in the application programming interface (API) by a form designer. Report quality levels and their meaning at each system operational state is not pre-defined. A form designer is provided with the flexibility to specify their own meaning for each report quality level. The use of the phrase 'policy information, is intended to encompass information defined by an administrator or by a form designer, but not by a middleware designer or programmer.

[0029] In addition to the two levels of report quality standard, which are Pessimistic Locking and Optimistic Locking, other levels are possible. For example, a user such as an administrator or API programmer could specify overriding policies to transfer data in a first-in-last-out sequence regardless of even potential business rules define a first-in-first-out sequence. This is standard and natural behavior where operations are written in the order in which they are received.

Claims

1. A method of report management in a workflow system, comprising:

defining in memory of a computer, a desired level of quality specifying a degree of a risk by specifying policy information by an end user;

receiving a request for an operation on a data bucket from an online form for carrying out a business transaction;

determining that more than one type of policy information is applicable to the data bucket to be reported;

resolving any differences between the more than one type of applicable policy information;

coupling an external device with the data bucketvia an intervening data pipe; determining a reporting policy of the external device receiving workflow data associated with the operation from the received request, the reporting policy being based upon pre-defined data entered by a user within the survey and specifying how and when to deliver data to the coupled device so as to achieve the desired level of data quality;

performing the requested operation; and delivering the performed operation to the coupled device in conformance with the determined reporting policy.

2. The method of claim 1, wherein the reporting policy requires that optimistic locking should be maintained for a set of operations on at least one data bucket

3. The method of claim 1, wherein the data is delivered in hierarchical format to the coupled device.

4. The method of claim 1, wherein the reporting policy specifies reporting requirements by selecting from the group consisting of optimistic delivery and at most once and the reporting policy specifies system operational states by selecting from the group consisting of bucketsize, pipe size, bucket transfer rate, pipe transferrate, and administrator chosen runtime expression that is extensible to support reporting requirements that are not known at time of survey workflow design and initialization.

5. The method of claim 1, wherein the connection is being established with the data pipe the data bucket while the data bucket is receiving incoming workflow data.

6. The method of claim 1, wherein the data pipe further comprises an internal cache for staging of incoming data pending for delivery to the coupled external device at the next checkpoint determined in the reporting policy.

7. The method of claim 6, further comprises:

sending a lock request to the coupled external device for the pending data at the internal cache;

delivering the pending data to the coupled external device;

determining receipt of an acknowledgement from the coupled external device; and deleting the pending data from the internal cache if the acknowledgement is received at the data pipe.

8. The method of claim 6, further comprises:

delivering the pending data to the coupled external device;

determining receipt of a write conflict error from the coupled external device;

determining error logging procedure from the policy information if a write conflict error is received at the data pipe; and notifying a workflow middleware of the error if so determined in the policy information.

9. The method of claim 6, further comprises:

blocking the data pipe to notallow incoming data requests from the middleware; delivering the pending data to the coupled external device; determining receipt of a retry request from the coupled external device; delivering a retry attempt including the same pending data to the coupled external device;

determining receipt of an acknowledgement from the coupled external device; deleting the pending data from the internal cache if the acknowledgement is received at the data pipe; and unblocking the data pipe to allow incoming data requests from the middleware.