[vabilisetty]

Hi All,

I want to unassign some order releases from my Shipment, whose external status is defined as per my requirement.I donot want the unassignment to happen through seeded Actions--- Unassign Order - Buy action, but i want to use an agent action of Unassigning in the Agent.

I am facing issues for unassigning in this case. All the Order Releases in the Shipment are not getting unassigned by this agent action; as they were to be with the "seeded Actions--- Unassign Order - Buy action".

Can anyone help on this.

Regards,
Satya

[LourensGlog]

If I read your post right you say that the manual action to unassign an order release works, but if you unassign this order release with an agent it fails.
If this is the case, check out the system log to figure out what caused the error, and you may want to contact Oracle Support, as it sounds like a bug.

[josephliang]

I have no problem unassigning orders by agent. But I have to say, sometimes it would be tricky.
May I know your OTM version and scenario you were trying to do.

[vabilisetty]

Hi Joseph,

I am presently using OTM 5.5 CU5, the agent do runs for un-assignment, but if we have a set of Order Releases , the un-assignment through agent basically triggers the un-assignment of the first OR rather than all in a sequential manner(as it happens through manual actions (Unassign OR - BUY)).

Please suggest.

Regards,
Murthy

[LourensGlog]

Here's a scenario where unassignment per agent may not work.
Order A: Location X to Y, 100 LB
Order B: Location X to Y, 50 LB
Order C: Location X to Y, 850 LB
Shipment created X to Y for 1,000 LB with Rate with minimum weight 200 LB

If you unassign Order C, the shipment is no longer feasible, as the total weight is now 150 LB and lower than the minimum weight of the rate, so OTM will throw an error. There may be another rate set up in OTM for shipments below 200 LB, but OTM doesn't select a different rate after unassigning, it just recalculates the existing rate.

What you may consider is instead of unassigning some orders, just replanning the remaining orders that you do want to keep planned. Downside of unassigning orders is that your shipments are no longer 'optimized', for example you have 3 orders from X to Z that don't fit on one truck and OTM creates 2 shipments. If you remove one order, you could still be stuck with 2 shipments, even though they could fit on just one. If you would replan the two remaining orders, OTM will create one single shipment.

[josephliang]

How is the unassign agent triggered?
Can you see any errors in the log?

I also had a case that unassign agent may fail.

If two agents are trying to unassign orders from the same shipment, deadlock may occur:

java.sql.SQLException: ORA-00060: deadlock detected while waiting for resource  

I have a workaround for this. Let me know if you need it.

[uma]

Hi Satya,

May be you can give a try this way if it suits your business scenario. Having agent type as Shipment and using saved condition select all the order releases related to the particular shipment and then use data type association as shipment to order release and do the unassigning of orders.

Hope this helps!!!

Regards,
Uma

[dkhemani]

Hi Joseph,
I am having a case where two agents are trying to unassign orders from the same shipment, and thus a dead lock is occuring.
Can you suggest the solution you had mentioned about in this post.

Regards
Deepak

[josephliang]

The deadlock issue, according to Oracle, unfortunately is "worked as design".

There are three workarounds on top of my head.

1. Use Wait in Error Handler
1) Add WAIT (1 second should be enough) and UNASSIGN ORDER actions in Error Handler.

Disadvantages: 1) Only can reduce chances of deadlock happening. 2) WAIT may delay process time.

2. Use Data Queue
1) Log on as DBA.ADMIN and go to Business Process Automation > Data Queue Management > Data Queue
2) Activate LIFETIME queue and adjust Thread Count, Batch Size, Polling Frequency accordingly.
** Thread Count should be as small as possible to minimize chances of deadlock.
3) Create a custom event, say OR - QUEUE UNASSIGN
4) Create an Agent listens to OR - QUEUE UNASSIGN and does UNASSIGN ORDER
5) Replace action UNASSIGN ORDER with QUEUE EVENT: OR - QUEUE UNASSIGN to your original agents

Disadvantages: 1) QUEUE EVENT may delay process time. 2) Only one LIFETIME Data Queue is available in OTM. Therefore, need to consider performance if LIFETIME Data Queue is widely used.

3. Shrink agentPlanning queue
UnassignOrder is handled by agentPlanning queue, which has 4 threads by default (if I remember correctly). However, simply shrink agentPlanning queue to 1 may affect other actions handled by the queue such as AcceptTender, BuildShipment, etc. (see glog.webserver.event.TopicQueueAssignmentsServlet) Therefore, my workaround is to designate UnassignOrder to be handled by a single-thread custom queue.
1) Modify glog.properties of OTM App
** Properties must be placed within Custom Thread Properties section

#--------------------------------------------------------------------
# Custom Thread Properties - Beginning
#--------------------------------------------------------------------
# Place all thread changes and properties here.
# This section will be used during GC3 Upgrades
#--------------------------------------------------------------------
 
glog.workflow.topicGroup=agentPlanningJoseph,1
glog.workflow.topic.group.glog.server.agent.business.order.UnAssignOrder=agentPlanningJoseph
 
#--------------------------------------------------------------------
# Custom Thread Properties - End
#-------------------------------------------------------------------- 

2) Restart OTM

Disadvantages: 1) Single-thread may delay process time. 2) Although I have been using this for several customers, it is still an unsupported approach by Oracle. Please note the risk.

I guess the best way is to raise an ER to Oracle and hope it will be fixed in the future.