Step1- Validate FNC Eligible For Stub

Refer to Function: StellaTools.AutoTestBox.UI.Wizard.Wizard.1_MaintainStub

Validate Function Eligibility

The selected plex object is tested via model api to see if the object is eligible to be registered as a test function
  1. Check object is type Function
  2. Check Function is a host object and not a library object
  3. Check Function is real and not implicit
  4. Check Function does not scope a panel
  5. Check Object is modifiable and not read only
  6. Check Function has a implementation name
  7. Is object generatable
  8. Check if Function is type Internal if WinC or ISeries then fail test

Create scoped Stub

  1. Check if Stub already exists then no need to add inheritance triples but check it is modifiable
  2. If No Stub then find StellaTools/Function: _AutoTestBoxStub and add the 'is a' triple to your test function, make real the stub

Define test function's input/dual variables/fields as locals with ín the stub

  1. Delete down any existing triples on the the stub MyTestFunction.AutoTestBox [StellaTools] and its scoped function MyTestFunction.AutoTestBox [StellaTools] .IdentifyDualFields
  2. Interrogate local model for test functions input variables and their fields
  3. Recreate the variables and fields as local versions within the stub
Why? This allows us during Registration Mode (after the stub is gen and built in Step2) to use meta instead of model api to determine and register the input and output fields and their variables. Secondly during Runtime mode the local versions of the fields will hold the input data retrieved form the ATB database and mapped to the Input on the call to the test function. 

Parameter mapping

Pretty neat so far but only one hurdle left how to automatically do the mapping on the Call Statement. Would be a shame if the developer during Step1 had to open the action diagram and do the mapping for himself before continuing....

We need as it were to mimic the behaviour of the 'Parameter Mapping Dialog' and add the local variables to the input variables.

Background Info: If you look at what is held in the large property of a function by StellaTools EditLargeProperty you will see the following constitutes unmapped call compared with a mapped call using the above screen cast example.


|0 10  Function: MyAmazingFunction
|1 MyInputVariable
|2 15 Field: InputFld
|3 <none>
|4 0 <none>
|7 10 Function: MyAmazingFunction
// MyInputVariable<InputFld> ???
ª+4 Call  MyAmazingFunction



|0 10 4400d082 Function: MyAmazingFunction
|1 MyInputVariable
|2 0 0 <none>
|3 MyInputVariable
|4 0 0 <none>
|7 10 4400d082 Function: MyAmazingFunction
// MyInputVariable MyInputVariable
|1 MyOutputVaraible
|2 0 0 <none>
|3 MyOutputVaraible
|4 0 0 <none>
|7 10 4400d082 Function: MyAmazingFunction
// MyOutputVaraible MyOutputVaraible
ª+1 Call  MyAmazingFunction


The trick was to use model api to update the large property with the second version but to do this we needed the local to first give up the 'unique block key' '4400d082'
So the wizard updates the large property with rubbish initially hence the warning log message: 

 Override 'Call  MyAmazingFunction' not matched by block number and instead defaulted

On reading the large property now the unique block key is available and we can format the second string to include our known local variables!


And we are left with a nice red Call because of the local overrides.

STEP1 Over