I'm thinking about make things in the better way to improve the system performance.
I have a dialog task that are sent to reponsables by a variable or expression configured in the own task. This variable is filled in a background task before this task.
Does anybody know what is the best way to do this in about performance ? If I change this functionality by a role if it will be better to performance.
Yes, you will almost always be better off performancewise if you can reduce the amount of WF steps. Using a rule (called 'role' up to 4.6) will do the agent evaluation in one step instead of two. Less logs, better performance.
Also consider the overall impact - a WF that only runs twice a day isn't really going to help much and is probably not the effort to change unless you're already doing other work on it. But 100's per day is a different story....
Ok, I agree with you less logs, better performance... It is incredble how sap writes on tables...even in log...
Here, we have over 60.000 events per day. There is a lot of workflows activated on production system and we had lost events problems too (of my workflow). Now I'm studying about the unnecessary workflows so we have to deactivate those. I found out workflows that were activated but nobody uses them and we are studying the possibility to deactivate the most of them.
Then...in my case I think I can try a rule or (as Rob had answered) a virtual method.
Maybe we just use different words for the same functionality, so just to make sure I'll explain what I mean with using a virtual attribute for the agent.
In the business object used by the workflow, you can through delegation extend the business object, with attributes, methods and events.
Now, instead of creating a method on the business object which yields 1 value, for instance responsible agent, you can place that abap logic in a virtual attribute, basically they do exactly the same, but when you use a background method in a task, it will create an RFC to execute it, with virtual attributes this won't happen.
I've wrote the wrong word. I wanted to say virtual attribute too, but I think I've wrote wrong because I'm not accustomed using this word and functionality.
I'll try using virtual attribute. But inside its logic will be a select statement too as the method.
If you can run the select during the object instantiation(select in the virtual attribute) or have the first step of the workflow do the agent retrieval (if they are fairly static) it may help improve performance
I didn't recognized a thing about virtual attribute to fill with the agents:
On this way, how can I fill this variable ? In my tests it is filled on object instance. On this way I think I must have one virtual attribute to each dialog task I have on the workflow.
Using virtual attributes instead of methods can be very easily accomplished if, in WF modeling the method only yields 1 parameter per workitem, this can be 1 value, or a 1 dimensional array, for this you can create a virtual multiline attribute.
If the method is more complicated then solving it through virtual attributes also becomes more complicated.
If it is getting too complicated you also loose transparency of the WF modelling, in that case other solution might be better.
How can I work with virtual attributes because the WF is very large and it has some sub-wf's too that inside each one there is a dialog task. So the necessity of fill agents is always, but different agents to each sub-wf.
did you understand ? I need to always to refill the agents.
Normally you bind the process' business object to and from subflows as parameters.
So if it's an HR-PA flow, either BUS1065 or EMPLOYEET is present in the wf as a parameter. When using subflows, these are binded.
But as I already said, your method is probably a bit more complicated to turn into a virtual attribute. The whole mentioning of virtual attributes in this thread is that they are performance friendlier than methods. And if you come upon a workflow in which a method can also easily be transformed to a virtual attribute, you should do it.
Each sub-wf searches by actual agents...but any sub-wf can be canceled and back to its father or can terminate both workflows.
I think the normal way is to use all the agents and a think I can (as ... had said) populate all the agents in the begin of the wf (maybe the father)...even I don't use all agent's virtual attributes/variables during the wf's... I think that searching for all the agents in a only time is best to performance.
I'm studying about it to the things better here....I think putting it (searching for all the agents) in the beginning of wf, will help in making the sub wf's run faster and will create each sub-wf's work items faster too, because it won't this step (searching for all the agents) before each one...
I think it solves two problems here...because here, another problem is that some times the Ztransaction trigger some terminating events for tasks that didn't had time to process and be created and standing for this terminating events...but it is another problem that I'll try to study for improve the wf design too.
I didn't know if both of you have recognized my problem....or design....but here each sub-wf has a step before dialog task that searches agents for its next dialog step by filling a multi-line variable that represents the agents to the dialog tasks...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.