GetaNewUD through REST API - errors with SysRowID

[Potato (Mickey Martin)]

I’m experimenting with using the REST API to create a new row in a UD table with GetaNewUD. I found the topic below which is helpful:

GetaNewUDxx (multiple records in transaction)

I’ve gotten closer, I found the NewRow was failing because of a failure to set a SysRowId - unfortunately it just silently failed with no explanation/indication. Now I;ve got my rows adding nicely to UD39Data, but on Update I get generic error: An unhandled exception of type ‘System.Data.ConstraintException’ occurred in Ice.Lib.EpiClientLib.dll Additional information: This property cannot be set to a null value. I must be missing some important field but I am cross-eyed at this point and sur…

However, I get various errors related to the SysRowID. I tried leaving it default as shown in the REST API screen (00000000-0000-0000-0000-000000000000), thinking this might trigger auto-generation of a good key for the new entry. This doesn’t work. Just as a test, I tried 00000000-0000-0000-0000-000000000007, thinking this might add a row assuming this ID hasn’t already been added to the database. I also tried removing all lines that define the SysRowID in the json data hoping that the API would be smart enough to generate it’s own unique SysRowID for the new row, which also didn’t work.

Since this is an API call, I can’t just use “new Guid()” programmatically as in the solution above with C#/custom code.

Maybe there’s a separate API call that will provide me with an available SysRowID? Any other thoughts on how to do this properly?

[Chris_Conn]

Hey i know that guy. A few work arounds off hand:
UpdateExt (you can just send key fields + your fields)
Function or UBAQ called via REST (where your logic inside does the new guid part for you)

Though I think ideally you would do that client side. There has to be some logic calling the REST.

[Potato (Mickey Martin)]

Thanks for the advice. UpdateExt is much easier to use; the json below was enough to populate an entry. I didn’t even have to populate all 5 key fields. The values for continueProcessingOnError and rollbackParentOnChildError are required.

{
  "ds": {
    "UDXX": [
      {
        "Company": "myCompany",
        "Key1": "myKey"
      }
	]
  },
  "continueProcessingOnError": true,
  "rollbackParentOnChildError": true
}

[Mark_Wonsil]

@Chris_Conn

Though I think ideally you would do that client side. There has to be some logic calling the REST.

Mmmm. Ideally? While Chris is a far better coder than I will ever be, I’m going to gently push back here and say:

This is for the same reason we don’t put business logic in the client for .Net. I agree with the previous statement: one could use an Epicor Function to do the server-side work and then call that function via REST. The client shouldn’t need to know the business details of the system it’s talking to. If Epicor changes the underlying logic, you would have to change all of the client code. Also, why should the client care about “rollbackParentOnChildError?”

A step above the Epicor Function would be to write your own API that is a proxy between Kinetic and the Client. Now, not only have you abstracted the client from the server code, you’re also able to hide the API-Key from the client AND add extra authentication between the client and the API if you choose.

But that’s just me…

[klincecum (Kevin Lincecum)]

What do you call all those carefully laid out interface controls, tabs, etc.
Restrictions placed on order somebody does something etc.
Or external systems calling in to do something.

That’s all logic, and it’s on the client side. While I agree you should try to keep what
you can server side, some just can’t be. It’s a blurry line.

[Mark_Wonsil]

@klincecum

That’s all logic, and it’s on the client side.

That’s client-side logic, and yes, it belongs there. I’m suggesting that we keep as much business and server side logic as possible out of the client. There are so many people on this list (including me) who are now paying the technical debt during our Kinetic upgrades for not doing so.

And this isn’t just Kinetic. MVC, MVVM, Onion/Clean Architecture also stress this separation.

Any examples that blur the line? I’m sure some exist, but I haven’t run into one myself.

[klincecum (Kevin Lincecum)]

No I agree with you, but sometimes when you say it, it sounds more exclusive.

Some logic does belong client side.

I realize you want to hammer it home, and I guess it’s warranted because it will
save people a lot of headaches.

I just want people to understand the distinction.

Everyone should always ask themselves:
“Would it make more sense to do it in the backend?”

and the more important question:

“Am I going to pay for this later?”

[Mark_Wonsil]