Assistants are a type of page in which you can define many steps. The assistant will then navigate between these steps depending on user actions. Dynamic Assistants are a special sub type of assistants which can be used when the steps involved cannot be determined at the time of development.
A common example for this type of assistant is a survey. In a survey the questions involved are defined by a user at run time, then if we represent a survey using an assistant we can map each question of the survey to a step, but the steps can only be determined at runtime.
The dynamic assistant looks almost same as a normal assistant albeit with some constraints. It can show only one input control at a time. Complex controls such as lists are also not supported.
Dynamic assistants are declared the same way as usual. However in place of steps, you need to specify the assistant as dynamic. See example below:
assistant Survey using SurveyAnswerSet { label = "Sample Survey"; savemode = OnFinish;
init command { execute { alert("start of survey"); } } steps { dynamic <<Set_up_Function_name>>(param1,param2); final step { list SurveyAnswerList; } } finish command { execute { alert("End of survey"); } } }
The IFS Aurena client needs certain information to render an assistant. It needs information related to steps, what controls should be there in each step, to which attributes data should be bound, where to save the data etc. But in a dynamic assistant there are no predefined metadata, it is instead gathered during runtime.
This information is retrieved by utilizing functions that return structures; these structures are predefined by the framework and are available for all projections. Implement the functions so that it retrieves the required values into the structures and returns them. The structures can be used in the PLSQL code as an ordinary structure declared in your projection.
You need to implement functions which returns the pre-defined structures. The IFS Aurena client calls these functions respectively to get the needed information.
When specifying an assistant as dynamic, a method name must be declared. This is the initial method the client framework will call to get information. This function returns a structure named FndDynamicAssistantSetUp
. It contains names of the functions the client needs to call to fetch info on steps, init commands, and finish command. This initial function is the only one you specify in declarative and this function in return should send the names of the other functions needed to load meta information.
Attribute | Description |
---|---|
Label | Title for the dynamic assistant |
Description | Description (not used for now) |
Entity | Entity |
InitMetaFunction | Function used to return Init commands |
StepsMetaFunction | Function used to return step information |
FinishMetaFunction | Function used to return finish commands |
NumberOfSteps | Number of steps in the dynamic assistant |
StartStep | initial step |
To define steps in a dynamic assistant you need to implement a function which returns an array of structures of type FndDynamicAssistantStep
. An array is required because each structure instance defines a single step, basically the array contains declarations of each step.
Query the dynamic instance within the function implementation (in PLSQL), loop through each item, and fill the structure. For example, for a survey you would loop through the survey questions and fill the relevant attributes of the structure with the appropriate value.
The FndDynamicAssistantStep
structure attributes are as follows. Note that all attributes do not need to be filled for all steps.
Attribute | Description |
---|---|
Label | Step label |
StepLabel | Label shown in the Assistant Progress indicator (default label) |
Entity | Entity Used |
Description | Description of Step |
Name | Name used for the client group |
Datatype | Data Type of the entity attribute for which data is collected |
ControlType | Type of visual control to be used for the entity attribute (default text control ) |
MultiLine | Should the Control support Multiline (default false) |
BindAttribute | Entity attribute to which control is bound |
BindAttributeLabel | Label to show for the Entity Attribute (default attribute name) |
SaveAction | Action method used to save the data in each step |
SaveActionParameters | Parameters for the save action: supports interpolation. Ex. (QuestionId:${QuestionId},SurveyId:${SurveyId},Answer:${Answer}) |
ProjectionName | Name of the Projection |
DefaultValue | Any default value to be used in the step (initial default values) |
Required | True if it’s a mandatory attribute |
Enumeration | Enumeration to be used in the step |
Reference | Lov Reference to be used in the step |
Visible | If a step is visible (default true) |
Enabled | If a step is enabled (default true) |
RemarkNeeded | If a remark attribute is needed for the step |
RemarkAttribute | Entity attribute to which remark is bound to |
RemarkAttributeLabel | Label of the remark (default attribute name of remark attribute) |
TerminateAllowed | If termination is allowed at this step (default false – survey specific) |
DynamicLovOptions | Options Available for check box group control (survey specific) |
FinishEnabled | determine if finish command should be enabled at this step |
Editable | step editable |
DefaultClobValue | default value when a clob needs to be loaded as a default value |
BlobUploadCommand | command to upload Blobs |
PreviousStepAction | function to fetch previous step information when previous ic clicked |
PreviousActionParameters | Parameters for the previous (step) action: supports interpolation. Ex. (QuestionId:${QuestionId},SurveyId:${SurveyId},Answer:${Answer}) |
Init and finish commands are supported in dynamic assistants same as in normal assistants. It supports both static and dynamic commands.
Static commands can be specified in the usual way for assistants. If you define dynamic ones (supports only alert and set operations) then they will be executed after static ones.
Defining dynamic commands is similar to defining steps. Implement a function which returns an array of FndDynamicCommandDef
structure.
Attribute | Description |
---|---|
Method | ‘set’ / ‘alert’ |
ArgName | value/ msg |
ArgValue | Argument value /alert message |
Result | not supported in dynamic yet |
Assign | Attribute to assign value to |
Next | not supported in dynamic yet |
Bound | command is data bound |
Name | command name |
Projection | projection |
Params | command parameters |
Dynamic assistants work by saving at each step because in most cases we need to collect values relevant to the same attribute at each step as well as when working with many records. This is done by first defining an action to save values in the projection and then specify that method at each step’s “saveAction” attribute. Then at the end of each step (when clicking Next) the framework calls that action along with the bind parameters. For different steps, we can use different save actions ( for example if different parameter types are needed etc).
You can also skip certain steps in a dynamic assistant. To do that the save action should return the next step along with any default values to the next step, this is again done again using a structure “FndDynamicNextStep”
Attribute | Description |
---|---|
NextStep | Next step number |
DefaultValue | Default value of the next step |
TerminateInfo | True if the can terminate the (survey specific) |
Other functionalities of assistant like final step are the same. You need to declare them in the declarative and works as in ordinary assistants.