Let’s get Func-y
A few years ago Epicor ERP introduced REST abilities for getting ‘Your Data, Your Way, On Your OS, Framework, Devices’. The data was freed up and exposed from every Service and Method exactly as the Rich Client has used since the beginning.
Additionally, a simplified API was created that spoke Odata 3 and wrapped up some of the complexity of the ERP APIs and provide a means to query the ERP APIs in a standards based syntax somewhat SQL like.
In 10.2.400, we enhanced those abilities by creating an additonal version of the REST APIs that spoke the Odata 4 spec and tried to simplify the Company handling and Access Scopes that were pain points of many in the original API.
In both of these, the ability to create BAQs and expose them via REST championed this ‘Your Data, Your Way’ mantra.
In 10.2.500, we are adding to that mantra - ‘Your Data, Your Processes, Your Way’.
The industry has seen a variety of new products in different platforms over the past few years to create a method or function as a standalone piece of logic and just telling the hosting platform of their choice to just make that function light up on the web to be callable anywhere. AWS Lambda, Azure Function, Google Cloud Functions all are efforts in that mindset - create a Function and just let a user call it. Don’t bother me with the details and semantics of all the hosting details, just get me a piece of logic I can call to centralize some logic. In 10.2.500, Epicor ERP brings this to market as Epicor Functions.
For those who are familiar with BAQs and with ERP REST, you know that you can create a new BAQ and call it directly via REST. This embodies the Your Data, Your Way Mantra.
In 10.2.500, there is a new flavor of Business Process Management that sits alongside Method and Data Directions - an Epicor Function.
Familiar BPM Environment
Functions maintain the familiar. In a BPM, you can select a service, a method and change logic before, after, or instead of the normal processes in ERP. The data inputs and outputs are predetermined for you based upon those existing methods.
In a Function, you get to choose what signatures you wish to expose. After that, the designer experience is very familiar. You can create your own processes and logic.
This logic is then callable from within ERP or externally via REST
Function Libraries
As a developer, trying to create ad hoc functions is powerful but managing those individually can be cumbersome for operations. To solve this, the concept of a library is there to bundle the different functions together. You can think of a library as a service or DLL that all your functions are combined together to make a unit of deployment. The URL to your function is familiar to REST v2 users
~/api/v2/efx/<YourCompany>/<YourLibrary>/<YourFunction>
This minimizes the potential conflicts when multiple groups create functions with the same name. Name your libraries uniquely and then consumers of your libraries will not have issues using your functions.
Dev Ops-y
Starting in Functions, ERP is trying to step towards a few better practices that fit a modern Dev Ops mindset. To start with, three new roles are created:
• Function Administrator
• Function Developer
• Function Power Developer
The Administrator cannot touch the Function, a Function Dev cannot touch administration and deployment handling and the Power Developer role is required to write C# code in a Function.
Additionally, instead of adding three new Check Boxes to the User Maintenance form, security is set by adding users to the new System Security Groups
Another aspect to the DevOps mindset is that Function Libraries are ‘Promoted’ and ‘Demoted’ from production.
Once Published, a Function Library becomes read only to editing. This allows an Administrator to control breaking changes to consumers of the Function.
Even if demoted for edit, developers are encouraged to think about their breaking changes to signatures when editing saved Functions. The intent here is to let you control your contracts to your consumers of your process. You no longer need to worry about Epicor breaking your integration points against your Function. You control your own destiny with regards to evolving your processes.
There is more here on our roadmap as Solution Workbench support is added.
Security Control
There are additional Security aspects available to you in Functions. To start with, you can limit usage of the Function to just support BPMs and not expose your process or calculation via REST. The ‘Internal Use Only’ flag will prevent the Function from being exposed via REST.
Additionally, the Access Scope understands Functions and their Libraries. This ability allows for the full granular access control that is supported by the rest of ERP.
Opt In
It’s no secret that ERP is a broad product with thousands of services and tables. Managing the migration between releases, the performance of the system at runtime and design time as well as the general struggle with usability when exposed to every possible table and service - it all can be overwhelming. To this concern, Function Libraries opt in to which Database Tables and Services a Function interacts.
Your Signature
In your Function, since you control exposing your own processes and calculations, you can control the shape of the data you wish to consume and expose.
This data can then be used in the Function Designer and leverage in consumers of the Function.
Why Get Func-y?
One of the questions I get a lot is ok, cool technology but what’s the point of this solution?
Cool tech sure, but what’s the business value?
What’s the problem you need to solve?
To do that, you need to look at the state of the customization approaches today.
The Rich Client allows you to change the UI, define some interactions in the UI through rules on the data elements exposed in the UI and call services to query or update data on the server.
The BPM on the server allows you to intercept existing logic and change behaviors.
This has limitations in a modern world. You cannot reuse your logic across the myriad of devices and form factors that exist today. Integrations within the data center, between applications and across the Internet are the norm. Additionally, even if you are just solving for the Rich Client, you cannot manage data integrity for your processes that span multiple services.
The server side in BPM has its challenges as well. BPM allows for powerful intercept and changes to support your business processes. Unfortunately there is limited abilities to change the shape of the data of these existing services. Additionally, logic you wish to leverage across many BPMs must be ‘copy and pasted’ onto each service method. This creates a painful maintenance situation to maintain multiple directives. The alternative to use an External DLL is a solution for C# and on premises but in the cloud, supporting External DLLs can be problematic. It also increases the skillset needed to create common chunks of logic representing your processes.
With these problems in mind, Functions.
As previously shown, create your processes and calculations as a Function. Leverage them anywhere. No SDK needed. This in in the box just as another flavor of BPM directive and exposed over REST just as you do today with BAQs.
Roadmap
It would be wonderful to solve every potential problem in one iteration and one release. The reality is that we have tons of ideas on what we CAN solve but we are at the point where we need feedback on priorities. We think this is a great milestone and delivers a ton of FUNCTIONality at this point.
But we know it’s not done and there will hopefully be lots of requests to add ‘x’.
Which x is first?
That’s what we need from you. Feedback. Kick the tires, leverage this in your environments and tell us your struggles. I don’t have enough ego to assume this solves world hunger. I assume it is at least a satisfying large meal at a drive up window. Hopefully a bit more of a nice linen tabled meal with the spouse, a candle and a glass of wine kind of feature.
It’s in the box in the Cloud Pilot and Controlled release for 10.2.500 announced this week and dropping this weekend.
