
Copyright © 2001, 2015, Oracle and/or its affiliates. All rights reserved.
DirectSQLUpdate
DirectSQLUpdate is an agent action which allows you to update an attribute of an Oracle
Transportation Management business object using a SQL statement. It is equivalent to a database
trigger, but the agent action is capable of refreshing Oracle Transportation Management business
caches to reflect the modified data. Performance tuning of SQL statements in DirectSQLUpdate is
important. It is also important to optimally configure the use of the cache refreshing options in the
action. For any given DirectSQLUpdate, you have the choice to refresh the cache or not. When
choosing to refresh the cache you have the further option to Parse SQL. If you have multiple
DirectSQLUpdate actions which update the same Oracle Transportation Management business object
in a single agent, you should configure the agent to only refresh the cache on the last update. An
exception to this rule is if actions in the agent itself are dependent upon the modified data.
The option to Parse SQL should be used whenever possible. By default, the refresh logic needs to
refresh all child data for the business object that is being updated. For instance, a DirectSQLUpdate
action in a shipment agent needs to refresh the related shipment, shipment stops, ship units, etc.
When SQL parsing is enabled, the agent will attempt to determine the specific business object being
updated, and only refresh this object.
Workflow Thread Tuning
Oracle Transportation Management workflow is based on a set of business topics and workflow thread
groups. A Topic is the Oracle Transportation Management terminology for a particular workflow
process. For example, AutoMatchInvoice is a topic. Each Topic is associated with a thread group by a
glog.property. For example, the following property associates the AutoMatchInvoice Topic with the
agentPlanning Thread Group.
glog.workflow.topic.group.glog.server.agent.business.invoice.AutoMatchI
nvoice=agentPlanning
A Thread Group is a set of workflow threads dedicated to processing a set of workflow topics. Each
thread group is given a number of threads that can be used to simultaneously process topics. When all
threads in a group are busy processing a topic, all additional topics are placed in a queue until a
thread becomes available. Oracle Transportation Management computes statistics for the amount of
time a topic spends waiting to be processed and the amount of time spent processing the topic. These
statistics can be reviewed with the Event Diagnostics page available on the DBA Diagnostics menu.
A long average wait time and/or a backlog of queued events may indicate a need to increase the
number of threads in a thread group. It is possible to temporarily add a new thread in the Event
Diagnostic page. Permanent changes to thread groups must be made with a change to the
corresponding glog.property. It is important to note that properties like the number of threads for a
thread group need to be explicitly removed in order to override the value. The whole key and value
must match the whole key and value that is being overridden. For example:
!remove glog.workflow.topicGroup=agentPlanning,3
glog.workflow.topicGroup=agentPlanning,4
This will change the number of agentPlanning threads from 3 to 4, assuming the default value was 3.
Adding more threads will not always increase performance. Another possibility is that some slower
topics are in the same thread group as a higher volume, but short duration topic. The faster topics
may be prevented from running by the slower topics. Adding more threads to this thread group may
not have a significant impact on performance. However, moving the slow topics to a new thread group
may improve overall system throughput by allowing the shorter topics to complete more quickly. The
following properties are an example of moving a topic to a new thread group:
glog.workflow.topicGroup=slowEventGroup,1
Comentarios a estos manuales