Advice needed, REST external App integration no Epicor Functions

Hello REST experts.

I’ve got a bit a challenge on my hands. We have a third party app that needs to request specific data via REST. Initially I thought “ok, lets do this with a BAQ, I’ve done that before”. Unfortunately the results going back requires some parts of the returned JSON as an array. I’m not 100% sure on what is the best way to go about this.

Is a BAQ the best way to do this? or is there some other way like using an updatable BAQ and returning the results back in one big single field.

Has anyone used the FileTransferSvc with REST, perhaps I can create a file with the uBAQ then send a response back with the filename to download and the file contains the fully formed JSON? Although I’m not that keen on having a third party app have that sort of access.

Yes we are using REST V2 unique API key and Scopes.

I’m assuming using information from here Creating JSON from C# - #6 by hkeric.wci and passing it all in one field, using the newtonsoft assembly will do the trick.

We are on 10.2.400 so no Epicor Functions. :frowning:

1 Like

Can you outline the general structure of the the expected Json? How many arrays? How deep? Is it one document at a time or a batch?

@Mark_Wonsil,
It looks something like:

  "credentials": {
    "userName": "yourUserName",
    "sharedSecret": "yourSharedSecret"
  },
  "transactions": [
    {
      "transaction": {
        "type": "CONNOTE",
        "transactionID": "ConnoteNumber(45)",
        "pickupReady": "YYYY-MM-DDTHH:MM:SS+10:00",
        "pickupClose": "YYYY-MM-DDTHH:MM:SS+10:00",
        "requestedDelivery": "YYYY-MM-DDTHH:MM:SS+10:00",
        "internalID": 12345,
        "accountID": "YourAccountCode(32)",
        "totalWeightKg": 1234.23,
        "totalVolumeM3": 1,
        "totalItemCount": 2,
        "reference": "Customer order Reference#",
        "reference2": "Secondary Reference#",
        "serviceCode": "The ServiceCode Requested”,
        "ATL": true,
        "addresses": [
          {
            "type": "pickup",
            "name": "Pickup Name(128)",
            "addr1": "Address Line 1(64)",
            "addr2": "Address Line 2(64)",
            "addr3": "Address Line 3(64)",
            "suburb": "The suburb(32)",
            "state": "State as code like NSW(3)",
            "postcode": 9999,
            "country": "ISO 3 Char code like AUS or NZL(3)",
            "contactName": "Contact name at pickup",
            "contactMobile": "Mobile number at pickup",
            "contactEmail": "Email of contact at pickup"
          },
          {
            "type": "delivery",
            "name": "Delivery Name(128)",
            "addr1": "Address Line 1(64)",
            "addr2": "Address Line 2(64)",
            "addr3": "Address Line 3(64)",
            "suburb": "The suburb(32)",
            "state": "State as code like NSW(3)",
            "postcode": 9999,
            "country": "ISO 3 Char code like AUS or NZL(3)",
            "contactName": "Contact name at delivery",
            "contactMobile": "Mobile number at delivery",
            "contactEmail": "Email of contact at delivery"
          }
        ],
        "pickupInstructions": "Long string shipping instructions(1000)”,
        "deliveryInstructions": "Long string shipping instructions(1000)",
        "transaction_lines": [
          {
            "reference": "LineReference",
            "description": "Main Description of line(128)",
            "comment": "Additional line level comment(128)",
            "weightKg": 12.12,
            "heightM": 0.5,
            "widthM": 0.5,
            "lengthM": 0.5,
            "itemCount": {
              "units": 1,
              "UOM": "EA(16)"
            }
          },
          {
            "reference": "LineReference",
            "description": "Main Description of line(128)",
            "comment": "Additional line level comment(128)",
            "weightKg": 13.13,
            "heightM": 0.1,
            "widthM": 0.1,
            "lengthM": 0.1,
            "itemCount": {
              "units": 1,
              "UOM": "BOX(16)"
            }
          }
        ]
      }
    }
  ]
}

Although we won’t be doing the credentials bit.

The majority of the data is stored in UD100 and UD100a, but I will have to go out to ShipHead,ShipDtl, TFOrdHed,TFOrdDtl,TFShipDtl,RMAHead,RMADtl,SubShipH and SubShipD I’m expecting.

Basically it’s an integration with a freight company, so that they can pull all our “configured” shipments and pickups, allow them to manipulate and send to their drivers handhelds/tablets.

And before anyone says, EMW can do sign and glass and they have a POD lite module…I know. :wink:

How close does the Epicor response need to match that? Using your BAQ idea you could have a BAQ that returned that exact JSON in a calculated field. But the response would be JSON inside of JSON. I would think your BAQ would have a parameter and only the one field that you populated with a directive.

If it needs to match exactly that format I can’t think of any way without something in the middle.

1 Like

Thanks @Carson. I think your right, perhaps the answer is for multiple BAQs , then they join the dots at their end

If you’re required to stay inside Epicor for this, BAQ is probably your best bet. Otherwise, you could build out a middle layer to broker the calls and format the data however it’s needed. This would give you full tooling build out the complex data structure via classes from perhaps even a single call to whatever BAQ you build out to present the data

4 Likes

Filling the data they need in the single field wouldn’t be bad in an external .dll. A couple of classes to define the data structure, a few linq queries to fill the data and NewtonSoft does the hard work. It’s probably a lot harder in the code widget since you can’t define the classes for the data structure.

Haven’t used the rest services in Epicor myself, but can you use external BAQs?

Could you perhaps use a SQL View to format the JSON?

1 Like

At the end of the day I really wanted to create a situation where the app at the other end is really acting like a bit of a plugin to Epicor, you setup a user, apikey, scope and the BAQs and away you go, no messing around with bespoke assemblies, etc.

We use a integration tool as a middle man for these types of situations. Tools like Dell Boomi, Oracle Integration Cloud, etc are out there so you wouldn’t need to build a bespoke tool. The Epicor side uses rest BAQs when the 3rd party app needs to pull data or BPMs when Epicor needs to send it to the 3rd party app.

2 Likes

Hmmmm, not that I have had any deep diving into any of this, but perhaps the solution could be a Kubernetes Microservice. Ideally the solution should be:

0.1. Secure and Compliant. As secure as practical and meet any compliance guidelines.

  1. Repeatable. (Should be able to easily integrate with any REST V2 enabled Epicor system)
  2. Fast and Simple to deploy. Ensures quick turnaround for the Freight company to get their value add to the customer up and going quickly, and should not need a whole bunch of propeller heads to implement.
  3. Simple Reliable, intuitive and Fast UI and Process. It needs to be able to “Just work” End users just want to press a button and the work is done, no waiting, no “Oh, yeah I need to remember to do this”. What I’ve learnt over the years no matter how much great documentation Epicor or I provide, it effectively goes unread.

Ok so it’s a bit of a Holy Grail.

@cfinley. I thought about your idea overnight. I think the issue may be that even if you used an external BAQ the data would be encapsulated in the JSON response as a JSON string. So whether you role your own in an uBAQ customer method or use an external BAQ pushing off the work to SQL, I think the result might be the same.

If you guys are on Office360 Microsoft has Flow. I haven’t messed with it myself but IIRC Jose has used it to interface with Epicor via REST.

Yes we have Microsoft 365. Still to work out the the costs involved with using PowerApps you need some of the higher plans to get all the abilities, if I remember correctly, but it may have changed since. It’s hard to keep up. You can do some awesome stuff.

I subscribe to Shane Young on YouTube, he has lots of good PowerApp stuff Shane Young - YouTube

I did look at it about 18 months ago with grandios plans of buliding a new Part request and approval workflow. But due to a lot of various levels of lacking (read into that as you will), I shelved the thoughts on the idea.

2 Likes

So just a quick shout out to everyone put in their advice. Not to mention all the other posts people have posted around similar issues REST in C#, REST JSON Arrays, Linqpad Epicor, and just as I thought all was for naught in the wee hours, the use of functions in BPM code.

I cannot thank everyone enough for their contributions, you helped me make an idea into a solution.

2 Likes