Precondition Optimization?

I'm currently working on optimizing aspects of webtop and I've been looking at Preconditions of menu items based on the research of our Oracle query logs.

For optimizing preconditions, WDK 6.6 guide recommends that preconditions should not call IDfSession.getObject.

It also recommends that they should not perform any types of queries inside the queryExecute method.
We currently break these recommendations. In multiple Preconditions, our code often checks the username and finds the roles/access rights (see attached example). I'm very concerned at the amount of preconditions for each object on each screen.

I've looked into multiple options:

1. Pass attributes into the precondition as an argument so that way we are not running constant checks for each precondition. In a perfect world, we would be to capture the role when the user logs in and store it as a variable that is passed in as an argument, eliminating the constant IDfSession checks. Do we really want to explore this?

2. Looked into presets (we currently do not use any) but presets don't look like a feasible option because our business rules are so specific. The preset examples in the Technical Fundamentals of Documentum Book are very limited. Plus, we would not be able to use presets on our custom action items.

3. I learned that preconditions can be fired on execution (value in the xml tag), but I don't want the user to view a bunch of action items he/she will not be able to access. That is the opposite of helpful as far as usability goes.

I don't see any true solutions. Maybe I should be focusing on other ways to increase performance speeds?

Thanks in advance for your input!

-Ryan

precondition_example.txt

Find more posts tagged with

Comments

DCTM_Guru

This may not be what you want to hear, but the easiest way to increase performance speed is to remove the precondition. EMC actually followed this strategy when they disabled the precondition for delete action and just let the Content Server throw an error if the user does not have appropriate permissions to perform the action.

rmtx97

So very similar to option #3?

I have seen other posts talking about generating friendly error pages for users that don't have the rights to perform that action.

So if I were to sell this idea to the customer, I would want to:

-Try to eliminate custom actions

-Try to eliminate preconditions

-Set preconditions to the onexecutiononly="true"

-Test the heck out of the system and show numbers proving a speedier performance at the cost of functionality/usability/increased frequency of permission error pages?

DCTM_Guru

There is always going to be trade off btw functionality and performance. Thats something I think you and your customer will have to decide. Your approach seems valid to me.

kcrkarthik

I approached this situation through a evaluator class. But still, user would see all the actions initially, but at least a user-friendly message is displayed in the same screen itself, rather than a pop-up or separate screen navigation.

Following are the steps:

a) create a evaluator class and implement the same checks that you would do in the pre-condition class (refer ActionEval)

b) create a class that would perform the action of displaying user-friendly message when the action is not allowed for the user (refer ActionFail)

c) create a class that would perform the actual action when the action is allowed for the user

d) configure the action xml to use the evaluator and criteria isallowed to decide which class to invoke at run time (refer WDK guide for this)

public class ActionFail implements IActionExecution

{

private static final String NLS_BUNDLE = "com.test.custom.actions.ClipboardNlsProp";

public boolean execute(String strAction, IConfigElement config, ArgumentList args, Context context, Component component, Map completionArgs)

{

NlsResourceBundle lookup = new NlsResourceBundle(NLS_BUNDLE);

MessageService.addMessage(lookup, "MSG_ACTION_NOT_PERMITTED", component, new Object[] { });

return true;

}

public String[] getRequiredParams()

{

return null;

}

public class ActionEval implements ILaunchComponentEvaluator

{

public static String CRITERION = "isallowed";

public String evaluate(String strName, String strAction, IConfigElement config, ArgumentList arg, Context context, Component component)

{

String actionValid = "true";

//perform the required checks and set the value of actionValid variable

return bPasteValid;

}

-Karthik

lastnitescurry

Personally I generally go with option 3 when getObject or DQL queries are needed.

I extend LaunchComponent (for example see LaunchComponentWithPermitCheck), and override the method "public boolean execute(...".

Yes the user will see menu items for actions that they can not do, but this already part of "out of the box" webtop, i.e. Delete action.

If you search for Documentum DFC performance tuning, you should find material (white papers, presentations) from EMC which demonstrate how much getObject calls with a query loop kill perfromance. Makes sense to find and use that in your business case

rmtx97

Thanks for the answers.
I think we'll have to re-evaulate areas of optimization based on these responses.
#3 seems like the only way to adjust, if we decide to go down that path.