Let's Get Funcy - Epicor Functions

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


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.
image image

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.

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.


This awesome! I am not cloud, and we are falling behind on upgrades, but it’s something that I will certainly use when I get the chance.

One question I have, when demoting a function for editing, does that turn it off altogether? How do you handle cases where the original is functioning, but you just want to do some upgrading or something to it. If the original needs to keep functioning during this development, how does that get handled?

1 Like

Thanks for sharing @Bart_Elia. Looking forward to our next upgrade.


can’t wait to kick the tires and belittle your work, constructively

1 Like

You are already jumping to advanced :wink:
There is a staging segment added to the URL

When Promoted, the ‘staging’ segment will be removed.


@jgiese.wci I think my phrase is enthusiastic feedback

1 Like

So when demoted, the production one stays active (in it’s unchanged state) then? When does the over write happen?

1 Like

Currently only one thing version is active - promoted or staged.
You are driving towards one of the things in the previously mentioned things on our list - multiple version support and hot swapping.

Not in scope and a part of this conversation on where is that in priority versus the other items @jgiese.wci will abuse me over :wink:


@Bart_Elia - This is superb! Thank you for sharing and documenting so well! Looking forward to testing this out.


So would this be a valid use case?
Instead of a generic “Create Order” functionality built off of BAQ endpoint with custom code running, a function would be built which accepts whatever user defined parameters and the custom logic would be build inside of the function?
Or perhaps instead of invoking a UserProcessWrapper BO BPM for custom logic, could this function be invoked both internally and externally?
Just trying to wrap my head around it a bit…thanks

1 Like

Wow, great concepts. I’m looking forward to working with these and refactoring some of the custom SDK-generated simple BOs into functions where I can! They are always a pain when it comes to upgrades.


@Aaron_Moreng - one of the major tenants of Functions is to encapsulate logic to be called from BPMs, external Apps, integrations, Client customizations, etc. Stop copy and pasting logic (code).

We don’t have the helpers in place in the client framework (yet) but we want to push more and more logic into Functions and out of the client code.


ahh ok I think i understand. So it’s essentially built into the framework and would be available to call from any of the potential calling applications/interfaces. Super cool, can’t wait!


This looks really awesome. It give us the ability to make custom BPM widgets!!

I didn’t see a custom code widget in the screenshots there so i guess that is on the list somewhere and if so that would get my vote for next feature to implement :slight_smile:

I think a function with custom code could remove our need to use the 64bit version of the client for some users.


1 Like

Look harder, it’s there

1 Like

It’s opt in. If the admin grants a dev permission to do c# widgets.
#DevOps #SeperationOfConcerns #BabySteps

1 Like

Fantastic! Go Epicor Dev Team!!!

1 Like

Sweet! First up, Solution Workbench so we can build/install solutions from one environment to another (or better yet commit to source) without a separate exe and helper apps. The CLI was a good step but having all the build/install logic on the appserver side instead of the client side would be great!


Wow! I have not other words at this stage

1 Like

Time to start seriously considering if we can fit in a 10.2.500 upgrade before too long!