It can create new business objects and their respective tables. Also it lets you modify the Kinetic UX Base Layers
Why do I need it?
This is a question for you to answer, but essentially, it allows you to create entirely custom business objects with their own tables, parent-child relationships, and more.
Value:
You are no longer limited to using UDXX tables for custom data. You can create properly named and fully functional tables.
It provides FULL CRUD (Create, Read, Update, Delete) endpoints for the business objects (BO). This means you can use GetList, GetById, GetRows, DeleteByID, GetBySysRowID, and all related oData endpoints without worrying about the mechanisms for insertion and retrieval.
These are also fully BPM (Business Process Management) enabled and available in BAQ (Business Activity Query) land.
Can you do all of the above without it?
Mostly, yes. You can create your own tables (probably not in the cloud) and quasi-âBOsâ by using Functions and UBAQs. However, it wonât be as cohesive as with this tool.
Use Cases:
Quote Worksheet Recorder
These values on the worksheet arenât stored anywhere; they are ârolled upâ from the Quote BOM. I need this in reports and other places, and rolling it up manually is painful. Enter my QuoteQtyMaint BO, which has all those fields in a new table. When an entry/change occurs in QuoteQty, a function is invoked that performs a QuoteGetByID and then loops through the Worksheet dataset, recording all these values in a neat package for further use.
Could I do it without the SDK?
Sure! But the table would be called UDXX, and the fields would be named MyAwesomeFields_UD, which makes the code less clean. I named the fields exactly like the original dataview, allowing for a BufferCopy to copy all fields at once â #Neat.
Are you familiar with Order Bookings? If not, you can skip this.
Order Bookings is a functionality in Epicor that forces Sales Orders Lines/Releases to ârecordâ bookings (i.e., changes in revenue, up/down).
Every time a line/release changes either quantity or price, a booking is recorded. This allows you to track sales trends by monitoring activity fluctuations. Although I think itâs a flawed measure, my company disagrees and wanted to use the Bookings functionality. However, due to some issues, such as bookings not being recorded if the order isnât set as ready to process or other minor actions, we found it unreliable.
Therefore, we developed Booking Service â a BO that records revenue (or cost) fluctuations for Sales Orders and/or POs. When a new Release is added to a SO or PO, it records an âAddâ transaction. Subsequently, any changes in quantity or revenue are tracked by recording a âReversalâ and an âUpdateâ with the new values, allowing for tracking value fluctuations over time.
Could I do it without the SDK?
Yes, for the same reasons as above.
Is it worth it?
It depends on the cost. We already owned it back when it was the âBig boyâ SDK, and I appreciate how it allows us to organize our custom tables more neatly. Additionally, having those tables nicely named and fully accessible in BPM/BAQ land is a valuable feature.
Hereâs how the BookerService âBOâ Definition looks (its pretty simple really)
No we are on prem but the Cloud SDK is just a dumb name to let you know that it works with the cloud. It works just fine on prem too.. Dare I say⌠better! Cause I can regen my own damn data model!
PS: I know the portal is coming yada yada⌠still I need my control
Yes, we are on SaaS Hardware/VMs but not running SaaS Epicor⌠I just rent someone else computer and we manage the entire thing have a really long cable from NJ to Redmond.
I guess thatâs 3rd Party Cloud Hosted Infrastructure as a Service IaaS
Jose - great writeup (your check is in the mail but donât hold your breath).
As Jose mentioned, the term âCloud SDKâ comes from the marketing folks to indicate it is an option for the Epicor Cloud customers. We have been somewhat slow rolling it out as the Table definition part does require a Data Model Regen which will be in the upcoming Epicor Cloud Self-Service Portal.
@klincecum - since you already have the portal, and you do a fair amount of custom extensions, the SDK is something I think you would really like.
The updated SDK allows you to create custom Tables and Services that the system treats as first class entities. Here is a quick recap of the features:
Define custom tables and columns - including ability to define a limited number of Index columns
Use the Service Designer to define the List and Rows datasets
Generate a User Defined Service that will include the standard methods - full CRUD support
Generate a Web UI form for maintenance of records defined by the service
Use AppStudio to add your UD Tables / UD Service logic to Epicor UIs
Generated UD Service supports the same REST Interface standards as the Epicor Services
Tables / columns will be available to BAQs and BPM
BPM Method Directives will be available on the Standard Methods in the User Defined Service
BPM Data Directives will be available on the tables
Standard Method, Table, and Field Security will work against the User Defined Service, Methods, Tables, and Columns
Custom tables can be defined to support attachments
ChangeLog Tracking is available
REST / Swagger Help will be available on the Standard Methods
The UD Services will be available via Automation Studio and Epicor Data Fabric