I’m looking at the REST api calls through the swagger tool, for example, the /PartRevs method.
I was expecting, when clicking on the “Model” link, to be told which fields are required on the Erp.Tablesets.PartRevRow object in order to be able to populate the “input” json object and call the method.
As it is, all the fields are marked “optional” (snippet):
Erp.Tablesets.PartRevRow {
Company (string, optional): Company Identifier. ,
PartNum (string, optional): The PartNum field identifies the Part and is used as part of the primary key. ,
RevisionNum (string, optional): Revision number which is used to uniquely identify the revision of the part, and is used as part of the primary key ,
RevShortDesc (string, optional): Short description of the revision. This is NOT the Part description. ,
RevDescription (string, optional): Used to enter a full description of the revision. ,
Approved (boolean, optional): Indicates if the methods of manufacturing have been approved for this revision. Only approved methods can be pulled into jobs/quotes. ,
ApprovedDate (string, optional): Date which this revision was approved for use by manufacturing/quoting. This is set to the system date when the user marks the revision Approved. It is not maintainable by the user. ,
and so on.
It is clear that in order to create a PartRev, the PartNum and RevisionNum are not optional, so I’m looking for a reference of some kind that will tell me with exactitude which fields are requested, and which are really optional for creation of Rows in any of the REST POST methods.
In Epicor you can hilight required fields, you can also use the data dictionary to figure that out. But your best bet is to do a Trace and Mimic what Epicor does exactly.
You see, while I can appreciate the use of the Tracing option, it does require a certain level of knowledge about the actual operations in the Epicor UI, whereas I’m “only” a programmer, and would prefer to rely on documentation, when available of course. This way I don’t have to spend too much (non-billable) time learning how to use the UI. I hope you understand
So, this data dictionary, is that a document in Epicor’s help, or?
The problem is that a lot of the way the Epicor works is based on Business Objects and Business Logic which is triggered by doing the actions in Epicor. You can’t just look at the fields on the DB, there’s an order to the operations and the calls that have to be made. It isn’t just CRUD but rather which BO should be called and which method should be called.
So although I understand your point if you want to succeed you are going to have to learn how Epicor does whatever you are trying to do in order to do it yourself correctly. Just calling Update or Insert will break a LOT of stuff in the Epicor logic, turst me!
Data dictionary is a document which lists all fields on the DB within Epicor.
As an example to create an order Epicor calls some of these methods in this order
order.GetNewOrderHead()
order.ChangeCustID()
order.ChangeShipByDate()
order.GetNewOrderDtl()
order.ChangePartNum()
order.ChangeUnitPrice()
order.ChangeOrderQty()
order.Update()
etc…
Skipping any or most of these can lead to issues unless you yourself take care of a lot of the work that is done in those methods.
I get what you mean, but for the current contract, the end customer is not allocating nearly enough resources for me to take an Epicor user training
I have some people who “know” how the REST API works, and they can help me with the order of operations, but at the moment I’m trying to understand which fields are required, and which are optional, only to find out that the “api docs” in Swagger is not really helping.
In your previous comment, you said something about Epicor highlighting the require fields. Do you mean that if I go to a screen, I can get the required fields to be displayed in a different color? That might be helpful.
What’s the easiest way to turn it on? Is that in the settings for my user, or on a “page” basis?
Yes you can in the epicor application highlight the required fields. But trust me if you do not follow the trace there will be a lot of pain to be paid I recommend you get and follow a trace. Again required fields are not all there is, this is your project but I am telling you this with 10+ years of Epicor experience. If you write your code to only care about required fields it will not be a good product and it will likely lead to major issues down the road. Better to go to the customer now, than to fail, sorry I know I sound preachy.
In the very least they need to have a consultant or someone internal that can map out the process
I’m green on REST, but having done my share of struggling to find out what BO calls do, I’d suggest one of two things:
Most preferable if your sub-contract circumstances permit would be to ask for a trace of an existing user doing what they want you to replicate. You don’t need to do it yourself.
If they’re awkward about that, you can sometimes get to where you need by opening Method Directives, finding the method you need, and looking at it, especially under “Advanced”. But try for the trace first if you can.
And yes, they do have a consultant, but I’d say I don’t trust them. They’ve shown a certain lack of interest working with other 3rd parties.
I think they would have wanted this part of the global contract as well, but since they have zero knowledge of the engineering application which we’re interface with, they lost it to us, and now, well, you know how it goes
I’ll turn on tracing and break a few teeth. At least I have this whole Dev DB almost only for me, so if I break things, it’s not so bad.
@josecgomez
just wondering if decompiling the assembly dll file will help in any way i.e. list the triggered methods per each UI interaction and their parameters? any idea?
The DLLs will contain ALL methods for an Object but the Trace will show you EXACTLY what the Epicor UI did in order to complete a task. Trust the Trace Luke*…
Mark W.
Do not mean Luc in this thread but if you want to get your inner Gedi on then that’s cool too.
I’ve had a good “cards on the table” discussion with the lead contractor this morning.
I think they better understand my needs and position, and maybe I was in a better position to express them from the discussions/help I got here from you guys.
Thanks all for the various paths forward you offered.
I do have other questions, but I’ll start new threads. I don’t like “hijacking” threads
I recommend you get and follow a trace. Again required fields are not all there is, this is your project but I am telling you this with 10+ years of Epicor experience. If you write your code to only care about required fields it will not be a good product and it will likely lead to major issues down the road. Better to go to the customer now, than to fail, sorry I know I sound preachy.
