Polymorphic Method

Polymorphic methods

A polymorphic method, when executed, will execute one or more “derived” methods. A derived method is a an (non-polymorphic) entity method. The list of derived methods that are executed for a polymorphic method is dependent on the values specified in request table of the polymorphic method.

A polymorphic method is defined by specifying non-null values in two fields of an entity method - derived_method_field_name and derived_method_field_mapping. The following three conditions must be met to setup a polymorphic method.

A definition for polymorphic method “TypesRead” will have values in the two fields as in the example below.

derived_method_field_name: TypeDomain
derived_method_field_mapping: is a JSON array of value pairs: {value, method_name}.
[
   {
      "value":"Account",
      "method_name":"AccountTypeRead"
   },
   {
      "value":"Instrument",
      "method_name":"InstrumentTypeRead"
   },
   {
      "value":"Contract",
      "method_name":"ContractTypeRead"
   },
   {
      "value":"Vendor",
      "method_name":"VendorTypeRead"
   },
   {
      "value":"Product",
      "method_name":"ProductRead"
   },
   {
      "value":"SubAccount",
      "method_name":"SubAccountTypeLookup"
   },
   {
      "value":"SubVendor",
      "method_name":"SubVendorTypeRead"
   },
   {
      "value":"Agent",
      "method_name":"AgentTypeRead"
   },
   {
      "value":"Address",
      "method_name":"AddressTypeReadTable"
   },
   {
      "value":"Notes",
      "method_name":"NotesTypeRead"
   }
]
The request table for the polymorphic “TypesRead” method will have at least one field with the value specified in the derived_method_field_name. That is, the request table must have at least one field: TypeDomain

If value in the request table field “TypeDomain” = “Account”, the method “AccountTypeRead” will be executed. Method “AccountTypeRead” is one of the derived methods, of the polymorphic method “TypesRead”.

It is also possible to execute multiple derived methods in one request. Multiple methods can be specified in a field that is an “array_of_base_field_name”. For example, the request table with field = “TypeDomains”, which is defined as an “array_of_base_field_name” of the field “TypeDomain”. The “TypeDomains” field may have values in one of the array formats – csv, json or xml. A value of TypeDomains = “Account, Instrument, Contract” (with csv array format) will execute three different methods – AccountTypeRead, InstrumentTypeRead, ContractTypeRead, and a combined result of all three methods will be output. Specifying null value in “TypeDomains” will result in execution and output of all derived methods.

Merged Output Data

The response tables of a polymorphic method may be merged to a single table or be output as a set of response table(s) of each executed method. A page configuration “MergeApproach” value determines whether the result is merged or not.

MergeApproach=0 or NULL represents no merge. In Polymorphic methods, multiple derived methods will be executed, and the response tables from each derived method will be output, as if each derived method is executed by itself.

Using the above example, when TypeDomains = “Account, Instrument, Contract” – three methods will be executed, and assuming each method outputs one response table, a total of 3 response tables will be output.

If TypeDomains has no or null value, all methods will be executed, and all tables of all methods will be output.

This is useful in fetching architecturally similar (“Types”) data together in one request, and yet show the data tables separately. In this merge approach, dynamic tables are output based on the request. The fields in each table may be static or dynamic.

MergeApproach=1 represents "Exact merge", where the generic method response table fields are filled with data from derived method response tables – for the common fields between tables. The common field is defined as

- Fields that are common with the same name

- Fields that are related by base field

The data from each derived table is mapped to the generic method table as in the example below.

Generic Method Table Field à Method=TypesRead – Table=Types	TypeDomain	TypeId	TypeName	ParentTypeId
Derived Method - Table ↓		Fields below from derived method table is mapped to generic method table field above, when populating the data
AccountTypeRead – AccountType	*Account*	AccountTypeId	AccountTypeName	ParentAccountTypeId
InstrumentTypeRead-InstrumentType	*Instrument*	InstruemntTypeId	InstrumentTypeName	Parent InstruemntTypeId
ContractTypeRead-ContractType	*Contract*	ContractTypeId	ContractTypeName

The field TypeDomain, which is specified as derived_method_field_name, gets its value from the request table. When merging records from multiple methods, the value in this field shows the method from where data is originated.

This is useful in fetching architecturally similar (“Types”) data together in one request, and show the common data merged in a single table. In this merge approach, only one table, and static number of fields is output.

MergeApproach=2 represents “Exact Merge" (MergeApproach=1), plus merge of all non-common fields in each table of the derived method. The number of fields could be high, depending on the number of tables to merged, and the fields in each merged table.

This is useful in fetching architecturally similar (“Types”) data together in one request, and show the data in a single table - common data fields merged, plus the fields unique to each derived table. The number of fields output will vary based on the request. In this merge approach, only one table, but dynamic number of fields is output.

Relations using polymorphism

Concept: Customer Configuration page uses the new concept of "Polymorphic relations". The polymorphism is explained briefly below

In Configuration tab, we have two key fields: Entity, EntityInstanceId . (The Entity - means "Cadebill Entity" and is different from NF entity. So, do not get confused between these two. We will be renaming "Cadebill Entity" to "Cadebill Object" later)

These two fields are generated using a union query similar to below.

select 'Account' Entity, account_no EntityInstanceId from customers.account

union all

select 'SubAccount' Entity, sub_account_id EntityInstanceId from customers.sub_account

union all

select 'Instrument' Entity, customer_instrument_instance_id EntityInstanceId from customers.customer_instrument_instance

union all

select 'Product' Entity, customer_product_instance_id EntityInstanceId from customers.customer_product_instance

union all

select 'Contract' Entity, contract_id EntityInstanceId from shared.contract

--some more unions for account user etc

Here EntityInstanceId represents one or more key fields - account_no, sub_account_id ... Or, EntityInstanceId represents multiple fields, and why it is called Polymorphic.

However, what field EntityInstanceId represents is based on value in "Entity" field. If Entity =Account, then it represents AccountNo, if Entity = Instrument, it represents CustomerInstrumentInstanceId field, etc.

We need to define this NF tool - as what EntityInstanceId means at what condition.

I have created the for configuration directly in the tables. Run the following query. It will show a JSON. We need to add to NF UI (but you can do this later)

select polymorphic_fields from mclsys.fields where field_name = 'EntityInstanceId'

By having polymorphism, we are are able to generate relations between two dissimilar fields.. between fields (AccountNo - EntityInstanceId), (SubAccountId-EntityInstanceId) etc..

You can see all new relations with query below

use Cadebill_Cloud_V33

select * from mclsys.entity_relations where parent_entity_name ='CustomerConfiguration' and parent_table_name = 'CustomerConfiguration'

So, there is no need to do additional client-side programming to manually set the relations.