IV72994: OBJECT PATH OF COST CODES IN MULTI WORK FLOW AGENT ENVIRONMENTS IS BEING CORRUPTED

APAR status

• Closed as documentation error.

Error description

• When a Project Template is applied to a Project in an
  Environment with two or more Workflow agents running, some of
  the created cost codes will have their Object Path corrupted in
  the IBS_Spec table. This corruption is visible through the
  system tab of the cost code where the hierarchy path will
  be missing all its ancestors and part of the publish name so
  that the path looks similar to \-99-IBM Cost code. These
  corrupt cost codes prevent the original budget roll up from
  working because the post transaction fails with the following
  similar error message:
  
  Caused by:
  com.tririga.platform.finance.service.PostTransactionException:
  In order to post a transaction, the cost code must be at least
  2 levels deep in a cost code hierarchy.  Cost code:
  \-999-IBM_Sample_Cost:
  SmartObjectImpl[ID=SmartObjectId[ID=19123260,Business Object
  ID=107260],Business
  Object=BoImpl[name=FinancialTransaction,id=107260,module=ModuleI
  mpl[name=System,id=18]]]
  

Local fix

• The point of running multiple workflow servers is to allow
  workflow processing to be done so it if fair to all users, not
  necessarily to increase the throughput of the number of
  workflows done. Adding more workflow agents to an environment
  may actually slow down processing, and cause undesirable
  results if workflows are not written with multi-threading in
  mind.
  
  It is best practice to assign secondary workflow agents to
  specific power users that tend to execute more workflows than a
  normal user.  If the secondary workflow agents are left wide
  open, a set of workflow instances will be picked up in
  parallel, and some may be processed out of order. It is
  important to know that my simply increasing the number of
  threads on a single process server, higher throughput could be
  had rather than splitting the threads across two servers.
  Typically the bottleneck of performance in the environment is
  the database server, and not the process server(s).
  
  If you already have a system deployed with multiple workflow
  agents, please consider either:
  - stopping the secondary agents, and increase the threads on
  the primary workflow agent server to be the sum of the threads
  across the other servers
  - or restricting the secondary agents so that they are
  exclusive for the set of power users.
  

Problem summary

• We have targeted  updating the documentation to clarify how
  multi-workflow agents should be used. An SMC wiki article will
  be updated with the informaiton.
  

Problem conclusion

• The point of running multiple workflow servers is to allow
  workflow processing to be done so that it is fair to all users,
  not necessarily to increase the throughput of the number of
  workflows done.
  Adding more workflow agents to an environment can slow down
  processing, and cause undesirable results, if workflows are not
  written with multi-threading in mind.
  It is best practice to assign secondary workflow agents to
  specific power users that tend to run more workflows than a
  normal user.  If the secondary workflow agents are left wide
  open, a set of workflow instances are picked up in parallel,
  and some can be processed out of order. It is important to know
  that increasing the number of threads on a single process
  server results in higher throughput than splitting the threads
  across two servers.  Typically the bottleneck of performance in
  an environment is the database server, and not the process
  servers.
  If you already have a system that is deployed with multiple
  workflow agents, consider either:
  * stopping the secondary agents, and increasing the threads on
  the primary workflow agent server to be the sum of the threads
  across the other servers
  * or restricting the secondary agents so that they are
  exclusive for the set of power users.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels