CTO Sales rules - rule actions / action type: External - documentation

Please see if this fragment helps you with this topic.

External sales rules actions provide a way to call a custom Pl/Sql procedure in the IFS database.  The Pl/Sql procedure can access any/all values in the configuration at that moment, and must return the full configuration back with any edits.  From within that procedure, Oracle could provide the means to call external libraries, user exits, etc. to other technologies – but we don’t have any examples of that approach.

To develop an external rule you need to:

1. Develop the rule – Add a new procedure to the IFS package Config_Sales_Rule_External_API.  This procedure is responsible for all the necessary calculations and edits to the configuration.  The configuration record is accessible from this procedure and must be returned with any changes (new/removed/edited configuration data).
2.  “Publish” the rule – Add the new external rule name and associated procedure to the IFS view CONFIG_EXTERNAL_DATA.  This makes the rule available in the drop down list of External rules.

The external methods must be added into the Config_Sales_Rule_External_API package and also added to its view, CONFIG_EXTERNAL_DATA, for rules entry validation and LOV.  They are then called upon in the following way from the rules logic:

1. The entire configuration (all values, quantities, etcc) are set to the public variable eval_rec in Config_Sales_Rule_External_API.
2. The rules logic calls the method Config_Sales_Rule_External_API.<Method-name> with no parameters.
3. The configuration is read back from the eval_rec variable in Config_Sales_Rule_External_API.

This way the entire configuration can be manipulated within the custom method. The eval_rec is a Config_Sales_Rule_Manager_API. config_sales_eval_rec  datatype, this is the type used internally in the rules engine validation and is defined as:

TYPE config_sales_eval_rec IS RECORD

   (num_chars_        NUMBER,

    char_id_          char_200_type,  -- TABLE OF VARCHAR2(200)

    char_value_       char_200_type,  -- TABLE OF VARCHAR2(200)

    char_qty_         number_type,    -- TABLE OF NUMBER

    char_flag_        number_type,    -- TABLE OF NUMBER

    config_family_id_ VARCHAR2(24),

    part_no_          VARCHAR2(200),

    spec_revision_no_ NUMBER,

    sales_quantity_   NUMBER,

    sales_unit_       VARCHAR2(200),

    sales_part_no_    VARCHAR2(200),

    customer_no_      VARCHAR2(200),

    site_             VARCHAR2(200),

    sales_group_      VARCHAR2(200),

    delivery_country_ VARCHAR2(200),

    messages_         VARCHAR2(32000),

    debug_mode_       NUMBER);

The contents are sets of char id / value / qty / flag – where flag is identifying if the characteristic is required, current value is invalid or set to deleted. The rest are just the info needed for validation of order info and the message attribute string sent back to client.

The code for the demo methods for rounding and setting all values are simple, here is the Demo_Numerics_Round method:

PROCEDURE Demo_Numerics_Round

IS

   idx_     NUMBER := 1;

   oldval_  NUMBER;

   rounded_ BOOLEAN := FALSE;

BEGIN

   WHILE idx_ <= eval_rec_.num_chars_ LOOP

      IF Is_Numeric___(eval_rec_.char_value_(idx_)) THEN

         oldval_ := eval_rec_.char_value_(idx_);

         eval_rec_.char_value_(idx_) := To_Char(Round(To_Number(eval_rec_.char_value_(idx_))));

         IF oldval_ != eval_rec_.char_value_(idx_) THEN

            rounded_ := TRUE;

         END IF;

      END IF;

      idx_ := idx_ + 1;

   END LOOP;

   IF rounded_ = TRUE THEN

      Client_SYS.Add_To_Attr('MESSAGE', Language_SYS.Translate_Constant(lu_name_, 'VALROUND: Values rounded to the nearest integer'),

       eval_rec_.messages_);

   END IF;

END Demo_Numerics_Round;