Let's Get Funcy - Epicor Functions

Yeah works fine. Different syntax than a BPM though.

using Ice.Tablesets;
 
this.CallService<UserFileSvcContract>(uf => {
  try
  {
    UserFileTableset newUser = new UserFileTableset();
    uf.GetNewUserFile(ref newUser);
    newUser.UserFile[0].UserID = propDcdUserID;
    newUser.UserFile[0].Name = propNewUserName;
    uf.Update(ref newUser);
 
    newDcdUserID = newUser.UserFile[0].UserID;     
  }
  catch (Exception ex)
  {
    pcOutMessage = ex.Message;
  }  
}
);
3 Likes

Sure, it works but “generally” the widgets tend to upgrade better in that issues show up quicker than in code since Epicor can’t write upgrade programs for code blocks.

1 Like

I don’t know that they show up any quicker than custom code either way it won’t compile. Widgets are ok for something simple but once it starts looking like the flying spaghetti monster I’m out and it all goes to custom code.

4 Likes

Oh, I’m not against code, anytime I want to use Json or call another REST service, it’s the only way to go. Sure, the code will just not compile either way but at least it’s “possible” for Epicor to see which Business Objects are being used in Widgets and know where they’re called instead of grep’ing code and finding all instances of Ice.Contracts.UserFileSvc or CallService< UserFIleSvcContract > or…

1 Like

I know this is an old topic, but hoping this can help others trying to start out with these REST functions. For now, my capability is RESTricted.

I’m testing out these functions and am having some issues. Trying to call through code in a form customization, I get an authentication issue.:

To try and troubleshoot, I thought I’d try accessing through browser with a simple function (Library ‘Test’, Function ‘GetANumber’) that takes no input parameters and returns a number, but when I try and run it, I get a list of the libraries and it doesn’t seem to run the function:

Any ideas what I could be doing wrong here?

I should note that calling the built in services work just fine:

1 Like

you certificate is not trusted by the client application. In browser as well you can see that Not Secure icon is shown. Do you use self-signed certificate?

2 Likes

Thanks Olga. I ended up installing the certificate on the client machine and it’s all working now.
Is this the expected solution? How do others manage the distribution of the certificates? Is it just one of those things that you add to your client install script for all machines?

1 Like

I am by no means an expert but my understanding is that if you buy a trusted cert then you don’t need to install it on the clients. That’s why you buy them and the trust is what you are paying for.

If you are going to pull data into Excel with the RestAPI then you will need a trusted cert as well - Excel is more fussy about the certs than the web browsers.

Brett

2 Likes

Andrew you should use a real trusted cert, they are free from let’sencrypt
Otherwise you can in your network create a Certificate Authority and have that Authority be trusted by all machines in the domain via active directory and gpo

1 Like

Jose mentioned the distribution methods but at a higher level, this isn’t just an Epicor requirement. When customers ask, “Are you protecting our data? Are you encrypting data in transit and at rest?” The way one protects data in transit is through public key encryption and that involves certs. If every server on the network is encrypting traffic, you’ve added a layer of protection against simple network sniffing. Without it, any system that uses Basic authentication would be sending usernames and passwords in the clear. Even if you’re using token authentication, you don’t want those tokens visible to sniffers. That is why Epicor and Microsoft requires the encryption.

3 Likes

Thanks for the suggestions guys. I guess the thing that confuses me is that the standard REST functions like Erp.BO.PartSvc/Parts work through the browser without the certificate, but not the custom functions.
Shouldn’t all REST functions have the same encryption requirements?

1 Like

Ah, there’s a difference. Functions run at the server using the standard .Net Business Objects so no cert required. The functions CAN be called called through an http REST interface but that’s optional. When it does, it leaves the process and goes over the network and THEN you want a cert. I like to think of functions as fancy BPMs with optional web access. :wink:

1 Like

I noticed that Epicor.Functions.Runtime is on the list of DLLs that can be referenced from a server-side configurator UD method. Being on cloud, I can’t decompile it to find out how to call into it. Does anyone know?

This would still require duplicate UD methods in every configurator. But those duplicates would just be a couple lines and there would be very little need to maintain them. The bulk of the logic could be in the EF.

1 Like

Have you tried calling it the same way you would in a BPM?

1 Like

There’s no InvokeFunction. It’s possible that it has some other name, but I don’t think so. My suggestion on the Ideas board to allow configurator expressions to call EFs was accepted as “possible future consideration.”

1 Like

EF’s are callable via REST. Would that work?

1 Like

I thought that you didn’t want to use rest calls to epicor business objects within epicor, but maybe I was misunderstanding.

Here is one post from Jose, but I swear I have read many more from him:

1 Like

Right and true. But Configurator is a different animal, especially Web Configurator. You don’t have access to the full set of DLLs in the configurator.

I’m interested to see what Kinetic Configurator will bring because all of Kinetic is REST (from the client anyway…) I certainly wouldn’t call REST from a BPM!

2 Likes

yes that’s what I thought too Mark, if we are talking Kinetic configurators here then I don’t think Jose’s previous posts apply. Also can’t wait for the kinetic configurator.

1 Like

It can be treated as a bug. Actually, the assembly filter was not adjusted.

1 Like