Data Query

This page is accessed via Business Process Automation > Process Management > Business Process Automation > Data Query.

Use this process to notify interested parties when a particular data condition is met. It is designed for recurring queries, for example, a nightly report of all shipments that exceed their maximum number of re-tenders, or all rates that have expired.

You can specify a saved query, for example, the same saved query that is used with the shipment, order, or invoice finder, and a notification party profile, as well as set up a schedule for when this process should run. An email is generated to notify the appropriate parties of records matching the saved query.

Data query supports long running tasks for notifications as well as custom lifetime events. If the data query is set up for notification, the Send Summary Only option is not selected and the number of matching records is greater than the Long Running Task Count, the data query is tracked as a long running task during notification.

1. Select a Data Query Type (shipment, order, order release, invoice, and so on).
2. Click Go. The page will rewrite based on your selection.
3. In the Based On drop-down list, select a saved query to base the search on (for example, all orders that are templates).

   Note: To define the query on this page, click Define.

4. Enter a saved condition in the Or on condition field. This field also allows you to create a new saved condition by defining a new query using SQL.
5. Select an option from the Raise Event drop-down list if you want Oracle Transportation Management to raise a custom event to trigger a workflow agent.
6. The Long Running Task Count controls if the data query is a long running task. The data query is long-running if the number of matched objects exceeds the number specified in this field. If the field is left blank, it defaults to 0; i.e. the process is long-running regardless of the number of matched objects. Note that this condition adds a small amount of overhead as the saved query is execute twice: once to get the # of matching records and, later, to retrieve the actual records. See the Long Running Tasks page for more details.
7. Set the Batch Size for the query. If the batch size is not set here, it defaults to the value defined by glog.dataquery.eventBatchSize.dqt.<query type>. If that property is not defined, then the glog.dataquery.eventBatchSize value is used.
8. The Notify field allows you to specify the contact to notify.
9. Select the Notify if no data is found check box to receive notification even if no data results from your query. This field restricts email to queries which return results; however, there may be a situation in which someone wants to be notified even in the event that there are no results (for example, where no results are a result).
10. Select the Send Summary Only check box to send a transmission that contains an ID only. If you do not select this option, have configured this query to notify someone, and the number of matching records is greater than the Long Running Task Count, the data query is tracked as a long running task.
11. In the Subject field, you can state what this is regarding.
12. In the Header field, you can enter text.
13. If you are running cluster scalability, specify a cluster to which this request should be assigned.
14. Enter a User Role. When you run, publish, or schedule a recurring process, you can specify the user role used to perform the process, just like when you run agents. The user role can be used to specify a separate VPD role or another domain to run the agent. When a recurring process is modified, the user role of the recurring process can be modified as well.
15. Select a Log Profile to generate focused logging when reproducing an error for the specific action. You cannot select a log profile when you choose to schedule a process, as automatic generation of action logs is not supported.
16. Select Execute, Publish, or Schedule to determine when the process will be executed.
17. Click Submit.

Once you submit the data query process, the data is stored in the database. Oracle Transportation Management periodically reviews the database to determine which processes should run based on the data that was submitted (specifically, the schedule data). You can display the data parameters for any process that you submit and change the settings or delete it.