ABSTRACT


creating models of data coming in from a collection/payload.



Hopefully fluttering around the back of your head is possibly the work done in step 0 the most important of steps before finding yourself at this point of the journey. Either way now is the time such knowledge will serve you.

 

For each model/collection that has been identified a nice recursive workflow will be taken for each.

 

The Process

1: Make a new model

2: Identify what abstract it must inherit

3: Make model available

4: Make properties

5: Establish operation methods

Make A New Model


Inside the Models folder create a new model in this case Customer.cs-this file can be copied and pasted to make a new model some parts will need to be renamed to make the new model unique.


Identify What Abstract


Depending on what is supported by the 3rd party system for each collection that the model is being made for it will have to inherit an abstract which determines if the collection has custom fields or not. This can either be

  • AbstractIntegrationDataWithCustomFields

  • AbstractIntegrationData 

Enter your necessary inheritance in this case it is AbstractIntegrationDataWithCustomFields next to

 Public Class "ModelName":


Make Model Available


In order to make the model available go back into MetaData.cs and inside the file is the function GetTables().

 

 

In here add a line similar to the one seen in this case for the model Customer.cs.

 

Syntax


Actual:

Tables.Add(GenerateTableInfo( "Customer", "helptext", (int) Integration.Constants.TM_MappingCollectionType.CUSTOMER , typeof(Customer)));

 

Simplified:

Tables.Add(GenerateTableInfo( Part1, Part2, Part3, Part4));

 

Part1- this is the label for the table when it is brought into IPaaS.com.

 

Part2- This is just some extra text that can be put in.

 

Part3- This is the Collection type this model is most similar to in IPaaS.com in this case the Customer.cs model most relates to the collection type of CUSTOMER.

 

Part4- this is the reference to the model you had created in the models folder.

 

Make Model Available Cont.


With the model available within the MetaData.cs we must also make the model available to TranslationUtilities.cs.

 

Inside of aforementioned file is the function GetDestinationObject().

 

 

For each model created a new case is needed inside the present switch. In the example one is made for the model Customer.cs.

Make Properties

 

Making our way back your model files being worked with we turn our attention to the Properties region.

 

 

For now in terms of compiling this does not need to be done but will need to be done anyway. for the variables passed in the collection Properties must be created for each and will may vary from system to system.

 

Here is a small example.

 

Generic Structure

[JsonProperty(“3rd party Variable name”, NullValueHandling = NullValueHandling.ignore)]

Public “data Type” “some variable name” {get; set;}

  • 3rd party Variable name= this is the name of the object as it comes in. **Case sensitive
  • data Type= simply the data type of whatever is being used may it be a string;int;float;boolean;object whatever just needs to be labeled for IPaaS.com understanding.
  • some variable name= this can almost be anything but for convention sake follow a simple ruling. For each variable in the third party no matter the casing of the variable utilize a capitalization system(in essence capitalize the first letter of each word).
    • E.G. Variable is bloodtype in third party would become BloodType.


Collection example


 Variable Test: Object

 {

    Int: int

    String: string

    Sub-Object: object

    {

        Name: string

        Age: int

    }

}


is sent It would eventually be transformed into:


Inside a file Titled Variable_Test.cs

 

    [JsonProperty(“Int”,NullValueHandling=NullValueHandling.ignore)]

    Public string Int {get; set;}

 

    [JsonProperty(“String”,NullValueHandling=NullValueHandling.ignore)]

    Public string String {get; set;}

 

    [JsonProperty(“sub-object”,NullValueHandling=NullValueHandling.ignore)]

    Public object “sub-object” {get; set;}

 

In the file named “sub-object.cs”--this file is to be created to allow for the sub-object to be passed in... should one not be needed the collection can be handled as a part of the whole. The separate file is needed only if to handle the collection as separate for example Variable_test.cs could be a model for Product and Sub-Object.cs could be a model for Product_Unit.

 

    [JsonProperty(“Name”,NullValueHandling=NullValueHandling.ignore)]

    Public string Name {get; set;}

 

    [JsonProperty(“Age”,NullValueHandling=NullValueHandling.ignore)]

    Public int Age {get; set;}

 

Despite these examples the overall structure is a JSON property and is ambiguous in nature and can support with the right know how other features such as conversions inside the property itself and or other ways of handling data within.

 

see here for more information on JSON properties

 

Establish Operation Methods 


Now depending on what is needed depends on what operations will be done.

 

For example, should it be decided that two collections are being done for an integration one is CUSTOMERS and the other being TRANSACTIONS. Now...

 

CUSTOMERS is to IPaaS.com

TRANSACTION is bi-directional

 

In this example TRANSACTIONS would need all Operation methods seen below to be completed while CUSTOMERS may not require all and would only need some of these operations. For the operations that are not needed they cannot be left blank for compiling and must be filled with "throw new NotImplementedException()".