 | |
Guidelines | |
While any developer is free to use SDK as they think it's best and easiest for them, there are a few things we can recommend you do to make your life even easier and ensure that a number of pitfalls are avoided.
1. Before starting any work in SDK we highly recommend you attempt the same workflow in the Epic UI.
This will save you a lot of time and headaches since SDK is usually a direct reflection of the UI.
The SDK object represent the screens with properties for each field you see.
Any required fields are required properties, validations are done in the exact same way and actions that are not possible on the UI are also impossible through SDK.
Fields on the UI that provide a list of choices will always have a corresponding SDK Lookup you can use (with Get_Lookup) that will return the same values you see on the UI.
2. Before invoking the Update method on any SDK object we recommend you do a Get on the same object.
The workflow should be as follows:
a) Invoke the Get method for whatever object you want to modify.
b) On the object returned by the Get make any modifications you want.
c) Invoke the Update method and pass the object you modified as a parameter.
By using the approach from above you will ensure that things like concurrency validations (where we prevent an object to be modified if it was already modified in the meantime by another person or process) work properly and also avoid any unintentional data loss caused by leaving a property empty.
3. As a general rule, defaulting is done on Insert calls and not on Update calls.
The idea behind this is to allow developers to enter data that's most similar with the data you'd get in Epic.
Documentation will tell you if a property gets defaulted, and in order to get that default it should be left blank.
If a blank is desired you need to do an Update on that object after the Insert is completed.
For more detailed information please refer to the Development - Defaulting section.
4. For convenience the Insert method usually inserts an entire object into Epic even though the UI necessitates several steps to get all the data in.
The idea behind this is to allow developers to make fewer calls when Inserting new data.
Some examples are the core Epic entities (Client, Broker, Company and Employee) where on the Epic UI insert screen there are fewer properties available for the user to modify, the rest being available only afterwards in the detail screen.
SDK allows inserting all properties with only one Insert call.
5. To optimize runtime, we developed the concept of flags to minimize the numbers of method calls required to insert/update/delete collections throughout most of SDK.
Some of the examples are:
Adding ProducerBrokerCommissionItem using Insert_Transaction