Fill the demo data in SAIL on click of a Button.

I hope you using CDT type variable on your form for all fields, if not then you need to do some hard work for each variable, else for CDT type, you can create a dummy rule (Lets say rule name : TEST_returnDummyData()) that return structure of your CDT along with dummy data, on click of button you can call this rule and populate your variable which is mapped to "Value" attribute of field.

TEST_returnDummyData():
{
/*CDT Field Name : Dummy Value */
Name:"XYZ",
Age:30}

on button Click :

a!save(ri!yourVariableName,rule!TEST_returnDummyData())

Fields on Form :

a!textField(
label:"Name",
value:ri!yourVariableName.Name)

There is no need to create the rule to return CDT value
local variable in load created with type constructor should be fine.
If say CDT is Employee, you can create local variable of type Employee like this:

load(

local!anEmployee: type!Employee( id: 123, name: abc, /*rest of CDT fields and values */ )

/*rest of the code */
)

Note: if CDT is not created, you can use the dictionary (adhoc structure). Even CDT is not a must.


And then you can save it in rule variable when the button is clicked.

Logic to use rule is to assign value in Rule input - ri rather than Local variable, this will reduce efforts of Changing "value" attribute of each component after demo (real time implementation when developer must need to use ri to pass data in Process).

In actual implementation - 90% of the times the data comes from rule inputs which come from activity class parameters of the user input task in the process model.
The additional rule creation step that you have mentioned is just returning you a CDT.

Please go through the approach I have suggested, in my approach I am already specifying to use the rule input of type CDT/dictionary.
It is just the source of inputs to the SAIL components which in real projects also comes from rule input variables (and not expression rules).

Now those rule input variables are passed by the caller (which maybe a user input task, another parent expression rule/a parent SAIL interface etc.)

It's up-to the caller to decide what and how to pass the rule inputs (any of the above methods).

You never know in advance how it will be called in a real project implementation.

So - creating an expression rule for just returning a test CDT instance offers no advantage.

In actual implementation - 90% of the times the data comes from rule inputs which come from activity class parameters of the user input task in the process model.
The additional rule creation step that you have mentioned is just returning you a CDT.

Please go through the approach I have suggested, in my approach I am already specifying to use the rule input of type CDT/dictionary.
It is just the source of inputs to the SAIL components which in real projects also comes from rule input variables (and not expression rules).

Now those rule input variables are passed by the caller (which maybe a user input task, another parent expression rule/a parent SAIL interface etc.)

It's up-to the caller to decide what and how to pass the rule inputs (any of the above methods).

You never know in advance how it will be called in a real project implementation.

So - creating an expression rule for just returning a test CDT instance offers no advantage.