Orchestration workflows often manipulate items in application workflows
using
sbmappservices72 operations. This section
discusses what you should and should not do when manipulating items in this
manner.
- It is not necessary to provide auth with
sbmappservices72 Web service calls because the
user that invokes the orchestration workflow is automatically granted a
Security Token on successful log in to
SBM.
This means that you can ignore the auth structure in
SBM Application Engine
Web service calls. However, if you provide credentials in the auth element,
they will override the Security Token auth. For example, this might be useful
if the calling user does not have privileges to update the item.
- Never directly modify the
State field of an
SBM
item. The application workflow should always control the state of items as they
progress through the process flow.
- Use data fields and decisions in application workflows to provide
process control. Decisions can respond to changes in data made by the
orchestration workflow. Asynchronous orchestration workflows can use Web
services to set data in tables; synchronous orchestration workflows return data
that can change the data in the item.
Do not make decisions in an orchestration workflow concerning what
happens in an application workflow. For example, to decide which outgoing
transition from a state should be executed, in the application workflow, change
data in the item, and use a decision on the outgoing transition in the
application workflow to route the item correctly. This has two advantages: it
decouples the application and the orchestration, so that changing the
application logic is less likely to affect the orchestration; and it makes the
application workflow more clearly describe the process flow.
- Never directly modify the
Owner field of an
SBM
item. The application workflow should always control the ownership of items as
they progress through the process flow. Use a
User field as the owner of a state, and change the user as
needed to control the ownership of an
SBM
item.
- You can use custom
Any-to-Any step
transitions to raise orchestration workflow events. Instead of raising events
on every application workflow transition to invoke a specific orchestration
workflow (for example, "update" or "create" to external tool), create custom
transitions from the
Any state back to itself. Then use transition
actions on each application workflow transition to execute the appropriate
transition from the
Any state. This results in an event definition
(Application Link) that does not change whenever a new or existing application
workflow transition needs to raise a specify type of event.
Note: To hide the transition button on the form, select the "hide
button" option on the
Options tab of the transition Property Editor.
To hide the form from the user, select the "quick transition" option.
- To optimize performance, the best practice is to send only necessary
data in an event and avoid passing large amounts of data. Passing too much data
in the event may result in a stack overflow error in the event manager (such as
java.lang.StackOverflowError). If you encounter this
problem with your event design, contact Support and reference solution S138101
to receive help with increasing the JVM stack size . However, to avoid
modifying the stack size, or accommodate larger sizes of “multi-“ data
elements,
Serena
recommends that you use the
sbmappservices72
GetItem call within the orchestration to retrieve that data.
- When there are multiple asynchronous
orchestration actions on the same transition, only one event of each event type
is raised. Events start orchestration workflows that will run simultaneously
depending on available resources, so the ordering of event actions on the
Actions tab has no effect on the execution order
of the orchestration workflows.
Copyright © 2007–2015 Serena Software, Inc. All rights reserved.