Are Epicor functions really this painful?

Kinetic ERP
21

If you want to be able to work on your function without worrying about promoting and demoting. You can create a second functions library with functions that call your original library. This way you can promote the second library and keep your original one demoted. This speed up the testing a lot in my case.

4 Likes
22

See I knew other people would have come up with a clever solution to this problem, thank you!

2 Likes
23

Confirmed on 2022.2.1 as well.

24

There is this idea out there too, to make it easier to test functions as you’re working on them. While there are a bunch of tools that you can set up to do it, the amount of setup is annoying.

https://epicor-manufacturing.ideas.aha.io/ideas/KNTC-I-2144

3 Likes
25

You can also do that by splitting functions. You can create a function that you use multiple times in your code and just call it from the other. Calling one function from another is super simple.

Moreover, if you just have a small code that can be reusable (lets say a HttpWebRequest) you can create a anonymous function (delegate) like that:

Action<string, string, string, dynamic> put = (_path, _cookie, _apiKey,_list) =>
{
  HttpWebRequest request = (HttpWebRequest)WebRequest.Create(_path);
  request.ContentType = "application/json";
  request.Method = "PUT";
  request.Headers["x-rs-key"] = _apiKey;
  request.Accept = "application/json";
  request.Headers["Cookie"] = _cookie;
  
  try
  {
    string body = JsonConvert.SerializeObject(_list, Formatting.Indented);
    byte[] data = Encoding.ASCII.GetBytes(body);
    request.ContentLength = data.Length;
    Stream requestStream = request.GetRequestStream();
    requestStream.Write(data, 0, data.Length);
    requestStream.Close();
    
    var response = (HttpWebResponse)request.GetResponse();
    using (Stream responseStream = response.GetResponseStream())
    {
        StreamReader reader = new StreamReader(responseStream, Encoding.UTF8);
        output = reader.ReadToEnd();
    }
    
  }catch(Exception ex){
    throw new BLException("put => "+ ex);
  }
};

and then call it from anywhere in the code like:

put(path, cookie, ApiKey, data);
1 Like
26

I’m sorry in advance because I’m asking this in total ignorance (we are just this week starting to truly test Kinetic), but I don’t understand this statement.

Is the answer that you can leave the API key blank, or there’s some other way to get a default one?

1 Like
27

You can leave it blank

28

I think I already voted on that, but I’ll go look again. Azure key vault would make a lot of sense… I know I have said that before.

1 Like
29

You must be authenticated in Azure Key Vault too :slight_smile:
In server application it is easy, but with browser app we have the same problem what we are trying to solve here - secrets cannot be stored secretly on the client. So key vault should support Azure AD auth for browser authentication. And you will have to use Azure AD.

30

I mean that’s great but . . . all the documentation still instructs you to fill it in. And if it changed after 2021.2 then I still have to fill it in anyway. Very confusing.

31

Oof, that would be something else.

We are going to this version, 2021.2 because we can’t get the SSL to work in 2022.1 (confirmed by support and an Epicor consultant and an integration partner that said another customer had the same issue).

So what this means is that I’ll be making customizations in 2021 with a blank API key, and then when the SSL is fixed in 2023 :crossed_fingers: then the customizations I made will all break when we upgrade?

32

I think you’re reading that backwards @JasonMcD. I believe the earlier version required it, and they fixed it in later versions to not need it anymore as long as the session header is valid.

1 Like
33

Indeed. As per my testing screenshot. I believe it is as follows

2021.1 - you need an API Key
2021.2 onwards - you no longer need the API Key in Kinetic Layers.

2 Likes
34

Oh OK, well that’s good to hear. I like being wrong.

35

I gave it some points this is a good idea.

36

Completely agree with @olga. This is where one needs a BFF - and we’re not talking about Olga in this case (even though she’s a good friend to have) but a Backend For Front-End. The client talks to an endpoint that authenticates the client then the endpoint tells the vault to get the value based on the authenticated user and inserts the API Key into the call to Kinetic. The secret is never exposed to the client.

I’ve been working on a demo for a while and hope to finish it up by this weekend. :crossed_fingers:

2 Likes
37

Correct. Technically BFF should store JWT tokens as well, browser should only use HTTP-only cookie to authenticate in BFF.

1 Like
38

Yes, use Azure AD or what Mark said (which I don’t know anything about but would love to learn more).

1 Like
39

Dropping in just to confirm this fact. API keys were intended for additional validation and constraints for external integrations which our own ui (customized) calling our own services with the current user’s rights are not. So we removed this requirement as unnecessary friction last year.

6 Likes
40

Thanks for dropping in Brian!