Enhancements to the ContextAccess extension API - reinventing the wheel?

Q&A
1

Hi

I have made a number of enhancements to the ContextAccess API extension (found in Learn → Examples) for my own use, and wondered about offering them to the community. But first, being new to Bonita I’d like to have my ideas sanity-checked.

Does the following sound useful and reasonable (ie is there an existing wheel I have re-designed?)…

Changes to ContextAccess-1.0.0
19th November 2016

1: Supplying the value "data" to a BDM object name in the task 'context' variable
   causes a full extract of the named BDM data (unfiltered). Eg:
	{
		"somePoolBusinessVariableName": "data"
	}

   Note: Using "*" (instead of "data") also works, if you prefer that syntax.

2: Giving the value "evaluate" as the action for task-local variable name causes
   the expression configured to provide the default value to be re-evaluated, and
   thenew value this re-evaluation generates to be returned. This does NOT change
   the stored value of the variable itself (which is [as normal] computed at the
   time the task is initialized - ie when it becomes "ready"). This means that
   these two entries CAN give different results.
	{
		"taskLocalVariableName": "evaluate"
	}
   and
	{
		"taskLocalVariableName": "data"
	}

   When evaluating the default value expression, the internal variable
   "evaluationFlag" is set to true. This allows the rule to know whether it is
   being called in this manner (because the variable is UNDEFINED in the standard 
   context). This means the groovy code to test it has to look like this. (not
   pretty, but it works) ...

	try { evaluationFlag }
	catch (err) {
		// Do the normal default value generating work
	}
	// otherwise -- do the work expected in "evaluation" context

   This means you can write code in the default value expression of a task-local
   variable which is ONLY executed when called from a "context" API call, and
   so gives a simple way to provide a simple custom "GET" stype API for your
   forms. This also also ideal if you want the expression to return a large
   volume of data which you dont want stored in memory or in the Bonita journal
   DB (this is somewhat different from the way the "transient" flag works, 
   which stores the value in memory until the task completed but not in the DB).

3: The value "task" provides a full dump of the current task structure.
	{
		"anyNameYouLike": "task"
	}

4: The value "process" provides a full dump of the current process structure.
	{
		"anyNameYouLike": "process"
	}

5: Some more new action words give the expected values..
	taskName
	taskDisplayName
	taskDescription
	taskDisplayDescription
	processName

   For example...
	{
		"anyNameYouLike": "taskDisplayName"
	}
1 Like
2

Hi,

I think the best way to collaborate on the project is to create a Pull Request on the Git repo and to get in touch with the repo’s owner.

Cheers

3

Hi Chris,

Looks interesting, apart from the formatting that is…

Here is a tip on formatting logs and code. You should also be able to edit your post to fix it.

Don’t use the editor code buttons they simply don’t work, Bonitasoft know this but it’s low priority. Instead use

< code >
< /code >

Around the text. This will format it much better. Just remove the spaces!

Here is a worked example:

1. Here is my code 2. In correct format

Regards
Seán

4

Hi Seán

I tried that, but it clobbers the indenting which is why I went for a “pre” block around the complete readme text. That seemed to work better in that the white space on the left hand margin was retained.

Chris