glog.server Properties

glog.server.agent.reassignDTAGid

Set to TRUE to enable data type associations to propagate all agent variables from the parent agent to the child object. The default is false because any existing DIRECT SQL UPDATE's dependent on $gid being the parent need to be rewritten. When this property is active, the system assumes that $gid is the child and $parent is the parent.

Default is true.

glog.server.appointment.servprov.allowExternalPredicate

19

Set to TRUE to apply the external predicate specified on shipment table of VPD profile to filter shipments on the Appointment Manager when logged into a service provider domain.

Default is FALSE.

glog.server.bngenerator.oracleSequence.gid.<BN Rule GID> = <oracle sequence>

This is a domain-specific property that determines whether a given business number generator (BNG) rule should use a simple Oracle RDBMS sequence in place of the synchronized business number generator. Sicne this is domain specific there is not a default.

If this property is found, the number is generated via Oracle RDBMS Sequence.

Note that maximum length restrictions on data fields is checked even for Oracle RDBMS Sequences. If the property is not found, the Business Number Generator checks for a cross-domain property: glog.server.bngenerator.oracleSequence.xid.<BN Rule XID>=<oracle sequence>

glog.server.bngenerator.oracleSequence.xid.<BN Rule XID> = <oracle sequence>

This is the cross-domain property that the system checks for if the glog.server.bngenerator.oracleSequence.gid.<BN Rule GID>=<oracle sequence> is not found.

Note that BNG XIDs are usually of the form: <rule mnemonic>.DEFAULT. E.g. the rule to generate monitor agent XIDs is: MONITOR_AGENT_XID.DEFAULT.

Since these are Oracle Transportation Management properties, you can embed spaces in the rule GID/XID by enclosing the property key in double quotes:

• " glog.server.bngenerator.oracleSequence.xid.MY BNG.DEFAULT"= my_sequence

glog.server.bngenerator.orderBase.useManualOrderBaseXid

Indicates if Business Number Generator behavior using MANUAL_ORDER_BASE_XID for order bases via integration should be used. By default, all order base XIDs will be generated using the business number type ORDER_BASE_XID.

Default: False

Do not change this property unless directed by Support.

glog.server.bngenerator.xreference.crossDomain

Used by cross-reference instructions in a business number rule definition.

Using "on" means cross-reference crossing domain is allowed. Using "off" means cross-reference crossing domain is not allowed. The setting is case sensitive. Without this property set, an error occurs whenever these arguments are used.

glog.server.derived.derivedata.calculable_fields_limit

This property controls the number of calculated fields on a finder. The more calculated fields on a finder, the worse the performance of the finder is.

Default: 10

glog.server.derived.derivedata.filterable_fields_limit

This property limits the number of derived data fields or criterion that can be applied at one time; that is the calculated fields that are filterable. The default is 10. An exception is thrown when this condition fails: "Exceeded Calculated Data Filterable Fields Limit".

glog.server.derived.deriveddata.filterable_pks_limit

This property limits the number of primary keys (PKs) that can come in as an input to be further filtered by the derived data filters. The default value is 500. When derived data needs to be determined on multiple PKs, performance may become an issue. An exception is thrown when this condition fails: "Exceeded Calculated Data Filterable Pks Limit"

glog.server.tenderresp.planner.allowExternalPredicate

When configuring dispatch-level tendering, OTM restricts some shipments from showing in the Tendering screen based on the User Association Value. To make it work properly, set this property to TRUE.

glog.server.tenderresp.servprov.allowExternalPredicate

When configuring dispatch-level tendering, OTM restricts some shipments from showing in the Tendering screen based on the User Association Value. To make it work properly, set this property to TRUE.

glog.server.workflow.lifetime.shipmentgroup.publishPartialShipmentGroupModEventAtChildLevel

6.4.2

Determines how often the following event is published: "partial shipment group mod event (Event: SHIPMENT GROUP - MODIFIED)" (for actions Add Partial Shipments to Shipment Group and Remove Partial Shipment from Shipment Group).

If false (default), publish the partial shipment group mod event (Event: SHIPMENT GROUP - MODIFIED) only once per action and not per each partial shipment added to/removed from the shipment group. If you want this event to be published for each partial shipment added/removed, set this property to true.

glog.server.workflow.mediator.supportGlobalGroup

Transaction mediation supports blocking across Integration Transmissions using a global process group designation. When set to true, a transmission, which has a ProcessGrouping in the TransmissionHeader, defined with a ProcessGroupOwner and the ProcessGroupOwner is not itself specified as a ProcessGrouping within the Transmission, then the ProcessGroupOwner (or Parent Group) will be setup as a global process group which will block on all transactions in the process group. For example, if the only ProcessGrouping in the transmission is defined as below:

<ProcessGrouping>

<ProcessGroup>MYGROUP.48785</ProcessGroup>

<ProcessGroupOwner>48785</ProcessGroupOwner>

<InSequence>Y</InSequence>

</ProcessGrouping>

then all transactions across transmissions that are designated in MYGROUP.48785 ProcessGroup will be sequenced globally.

Set to true to enable the functionality.

glog.server.workflow.mediator.synchronization

The default for this property is "tight" to prevent any impact on 6.1 behavior and performance. Also you can set it to "twoPhase." The two-phased mediator synchronizes access to mediator data structures when an item is added to the mediator. This property requires that each server reboot.

glog.server.workflow.notify.orderEvent.includeOrderBaseRemark

glog.server.workflow.notify.orderEvent.includeOrderStatusHistoryRemark

glog.server.workflow.notify.orderEvent.includeOrderBaseStatusHistoryRemark

glog.server.workflow.notify.orderStatus.includeOrderBaseHistoryStatus

glog.server.workflow.notify.orderbase.includeOrderBaseStatusHistoryRemark

These properties control the inclusion of remarks on order, order status, order base, and order base status builders.

glog.server.workflow.tender.allowDuplicateTenderRequest

Allows you to create a duplicate tender request even if there is an outstanding tender for the shipment.

glog.server.workflow.tender.enableTenderTimeout

This property is used to turn on/off the tender timeout timer based on response time for the tender. The default is TRUE.

glog.server.workflow.tender.redriveOnPickupChange

22A

When the property is set to false:

• If you provide only pickup time, the pickup time is set to the shipment start time and on the first stop's estimated arrival time.

• If you provide only dropoff time, the dropoff time updates the last stop's estimated arrival time. 

• If you provide both pickup and dropoff time, the pickup date is set to the shipment start time and on the first stop's estimated arrival time. The dropoff time updates the last stop's estimated arrival and departure times. 

Note: The rest of the times on this stop and other stops will not be recalculated.

When the property is set to true:

• If you provide only pickup time, the pickup time is set to the shipment start time and on the first stop's estimated arrival and departure times. 

• If you provide only dropoff time, the dropoff time updates the last stop's estimated arrival and departure times. 

• If you provide both pickup and dropoff time, the pickup time is set to the shipment start time and on the first stop's estimated arrival and departure times. The dropoff time updates the last stop's estimated arrival and departure times. 

Note: The shipment is re-driven to update the time on the rest of the stops. If both pickup and dropoff time is provided, the shipment is re-driven after updating the last stop estimated arrival time.

glog.server.workflow.tender.retenderOnTimeout

On a tender timeout, retendering is allowed if this property is set to TRUE. Default is TRUE.

glog.server.workflow.tender.steptender.minResponseTime

The minimum response time which is allocated for a carrier to respond to a tender. Default is for 15 minutes. Read an example of how this property works.

glog.server.workflow.tender.useLaneTenderCache

21C

When this property is set to true, the system uses new improved cache. If this property is set to false, the system uses old cache.

Default: true