How to Modify, Add and Remove Inputs

Most inputs present in the package are handled by InputManager available in AGR_InputLib library.

InputManager is a solution that enables dynamic management of inputs, reordering, containers, turning on and off (if not required by underlying code) and other functions.

In order to add an input there’s several steps that have to be done:

Step 1. Define the Logic that will use the InputManager

InputManager can be used in various places: Header, Line Item logics, Formula Types or other places. The most important part defining whether the InputManager can be used is if the inputs that will be defined are supported by the solution, so as long as the input you want to define is one of the ones listed below, then it should be fine:

• Void – usually used when there’s a behaviour that InputManager needs to do, without generating any input. This can be used for example to hide system Header inputs.

• Basic Input – used for inputs generated using .getInput() call from InputBuilderFactory.

• Configurator – used for generation of Configurators using api.inlineConfigurator or api.configurator.

• ConfiguratorEntry – used for generation of Configurator Entries inside Configurator logics generated using api.createConfiguratorEntry.

• Broadcast – special type of Input used only for FormulaType InputDefinitions, makes it so the input will show on Agreement Line Item instead of the Inputs tab of a Formula. This input is a Configurator Entry.

• Container - special type of Input used to group other inputs into sections, for example rows or collapsible sections. The Container has to contain other Configurator Entries and be generated using for example using createRowLayout().

The logics that use InputManager currently are:

AGR_FormulaBasedPricingHeader
(defined in AGR_FormulaBasedPricingHeader_InputDefinitions CP)

(Header)

Open

AGR_FormulaBasedPricing
(defined in AGR_FormulaBasedPricing_InputDefinitions CP)

(Line Item)

Open

Inputs displayed below Formula depend on defined Broadcastable inputs

AGR_FormulaBasedPricing_FormulaConfigurator
(defined in AGR_FormulaBasedPricing_InputDefinitions CP)

(Line Item)

This Configurator handles the display of Formula Type specific inputs.

More on each logic can be found in [link to Logic Docs]

Step 2. Find appropriate Company Parameter to fill the Input Generation configuration

There are several predefined Company Parameters that hold the configuration of Input Manager inputs. Those Company Parameters are divided based on the logics that generate the inputs, therefore which one should be modified is strictly connected to the choice from Step 1.

The predefined Input Generation tables are as follows:

• AGR_FormulaBasedPricingHeader_InputDefinitions - defines the inputs generated on the Header of Agreement

• AGR_FormulaBasedPricing_InputDefinitions - defines the inputs generated on the Line Item (additionally Broadcast inputs are generated there as well, but they are not a part of this table)

• AGR_Dashboard_ScenarioComparison_InputDefinitions - defines the inputs shown on the Scenario Comparison Dashboard [link to Scenario Comparison Dashboard] article

• AGR_Formula_CostPlus_InputDefinitions - defines the inputs present on the Input-Based Formula when AGR_Formula_CostPlus is selected as the used Formula Type

• AGR_Forecast_CostPlus_InputDefinitions - defines the inputs present on the Header when AGR_Forecast_CostPlus is selected as a Forecast Engine

• AGR_Forecast_Average_InputDefinitions - defines the inputs present on the Header when AGR_Forecast_Average is selected as a Forecast Engine

• AGR_Formula_ExceptionsConfigurator_InputDefinitions - defines the inputs present in the Product Exceptions table that is part of the Cost Plus Formula Type and Cost Plus Forecast Engine

• AGR_FormulaHeaderAttributesConfigurator_InputDefinitions - defines the inputs present on Attributes section of a Formula Designer Formula tab called “Inputs”

Inputs are defined using Company Parameter tables with defined and set structure, which is as follows:

• Table Type: JSON

• Value Type: JSON2

• Columns:

  • key1 – Lookup Key

    • This is a key defining the “set” of inputs that will be used during generation.

  • key2 – Input Name

    • Name of the input. This name can also be used as a calculation parameter for the Calculation Engine. This name must match the name that the input is created with in the code.

  • attributeExtension___executionPath – Execution Path

    • Generation Path for the input. Provided in format libs.<name of lib>.<name of element>.<name of method>. The generation path return value must match the Input Type of the input, defined below.

  • attributeExtension___order – Order

    • Integer indicating the order of this input compared to others. Inputs are ordered by descending order.

  • attributeExtension___inputType – Input Type

    • Type of the input generated by the Execution Path, this is used to handle different contexts, for example Configurators or Broadcasted inputs.

      • Void – the Execution Path returns void, useful for example for hiding system inputs or other cases where the value is not needed.

      • Basic Input – ExecutionPath returns the input generated using .getInput() call from InputBuilderFactory.

      • Configurator – ExecutionPath returns the Configurator input Map using api.inlineConfigurator or api.configurator.

      • ConfiguratorEntry – ExecutionPath returns the ConfiguratorEntry generated using api.createConfiguratorEntry.

      • Broadcast – ExecutionPath returns the ConfiguratorEntry generated using api.createConfiguratorEntry.

      • Container - ExecutionPath returns the ConfiguratorEntry generated using api.createConfiguratorEntry that contains other Configurator Entries

  • attributeExtension___isActive – Is Active

    • Boolean flag indicating whether the input is shown or not. Please be careful when turning off inputs that may be expected to be present by the underlying code.

  • attributeExtension___containerInputName – Container Input Name

    • Defines the name of a Container Input that will hold currently defined Configurator Entry. This mechanism is used to group inputs into rows or collapsible sections.

Step 3. Define the Input Generation method

The Input Generation method has to follow a certain signature. First the name of the method has to match the name (and place) that the ExecutionPath in Company Parameter defined in Step 2.. Second it has to have a parameter called inputs of type Map - this allows access to other inputs generated previously (for example to create dependencies between Configurator Entries).

Example Input Generation Method for a Decimal Entry could look like this:

The Execution Path to it could be for example libs.MyInputs.MyConfiguratorEntries.getDecimalEntryInput

Step 4. Generate the Inputs

After the inputs have been defined, they can be generated in bulk by calling an appropriate method on an instance of the InputManager from Step 1.:

• getInputs – Generates all inputs defined as Void, Basic Input, Configurator. Used for example for line item logics, headers, dashboards etc.

• getConfiguratorEntries – Generates all inputs defined as ConfiguratorEntry or Container. Used for Configurator logics.

• getBroadcastConfiguratorEntries – Generates all inputs defined as Broadcast. Used for Broadcast inputs. This mechanism is already handled by the Accelerator Configurator build for this purpose: AGR_FormulaBasedPricing_FormulaConfigurator.

This call returns the values of the inputs. In predefined logics there usually is an element called InputGeneration, which calls one of such methods. It also is used to access any values returned from those inputs in the logic.

For example to access the value of the input generated in Step 3. one would call out.InputGeneration.getAt("decimalEntry") to retrieve the value entered by the user.

Remember that all inputs generated are automatically appended as Calculation Parameters [link to article] that can be used when defining Input-Based Formulas [link to article].

Step 5. Validate proper generation of inputs

Last step is to navigate to the place where logic from Step 1. is run and validate whether the inputs have been properly generated.

(Optional) Add your own Input Manager logic

If you want to create a new logic that will use Input Manager, then InputManager needs to be initialized in it by calling: libs.AGR_InputLib.InputManager.getInstance(<CompanyParameterName>, <LookupName>)

where:

• CompanyParameterName is a name of the input generation table defined in Step 2.

• LookupName is the value of key1 column of that table that defines the set of inputs used by this logic - one Company Parameter can store multiple “sets”, this solution allows to store inputs that belong to similar “context” in one Company Parameter - for example Dashboard logic that calls a Configurator and Configurator Entries of that Configurator logic.

How to Add Container

Adding a container enables reordering, or grouping inputs into sections. Follow the steps below to add and configure a container.

Step 1: Define Methods

Define the methods within logics in the Groovy library that create Configurator Entry inputs.

Example

To edit inputs on the agreement header:

1. Navigate to Logics > Calculation Logic > Groovy Library > AGR_InputGeneratorLib logic.

2. Edit a desired element. For example, AGR_FormulaBasedPricingHeader_BoundsConfigurator. Here you can find getBoundsRowLayoutInput() that uses createRowLayout() located in libs.AGR_InputLib.CommonInputGenerationUtils.getRowContainerInput to display inputs side by side. You can also add inputs into the collapsible section using createCollapseLayout().

Step 2: Find Appropriate Company Parameter

For instance, if you're working with the Agreement Header inputs, open Company Parameters and locate the predefined AGR_FormulaBasedPricingHeader_InputDefinitions table.

Here you can see table containing all inputs (including containers) used on the header. For more details, refer to How to Modify, Add and Remove Inputs.

The table contains following columns:

• Lookup Key: Lists the keys used to look up specific parameter values related to Agreement Header.

• Input Name: Provides the names of the inputs used within the configuration of the formula-based Agreement Header.

• Container Input Name: Specifies containers where the corresponding input is placed.

• Execution Path: Here you can find the execution path in the Groovy Library (Administration > Logics > Calculation Logic > Groovy Library) where the input definitions are located, pointing to specific methods used to create the inputs.

• Input Type: Defines the type of input, such as Container, Configurator Entry, Basic Input, or Void. For more details, see How to Modify, Add and Remove Inputs | Step 1. Define the Logic that will use the InputManager.

• Is Active: This column uses a checkmark (✓) to mark whether the input is currently enabled.

• Order: This column indicates the order in which the inputs are displayed.

Step 3: Add Input to Container

To add an input to a container, specify the input name of the desired container in the input’s Container Input Name column.

In the following screenshot, you can see two inputs of the Configurator Entry type assigned to the boundsConfigurator_boundsRowContainer container (the Container input type).

The used container displays the two inputs side by side: