Is it still the case that Kinetic Cloud customers cannot create/run external BAQs?
I found an older post from years ago saying that Cloud customers could not do so, which makes sense insofar as external BAQs required ODBC (which Epicor would not let us create on their cloud servers). But I didn’t know if this has changed; e.g., perhaps by using an agent-based ODBC connection.
Not at a cloud employer at the moment, but I believe that’s still the case, Tim. You can have ODBC access to a replication instance though. If you’re looking for access to something besides Kinetic data, then the current method would be to create an API in front of that external database. You would have to describe your use case to get a deeper answer.
Thanks. At this point, I’m just exploring what is possible or not, as there may be potential need down the road for something like an external BAQ.
This is just me, but I’ve been trying to subscribe to Jeff Bezo’s API Mandate and avoid direct access to data stores. The External BAQ does not fit into that worldview. YMMV.
Until the username and password gets stored in the users local datasources!
#5 holds the meat of the message: the API should be externalizable and open for the world to use. Could you use ODBC as an API technology?
Technology like ODBC and JDBC are tightly linked to the tables by default. If you have a database product talking to clients who need to see the table detail, then yes, ODBC and JDBC are proper APIs. One could also use ODBC to expose VIEWS or a Stored Procedures that can enforce row level security and not expose the internal tables, yeah, I can also see that case too.
It really all depends on the use case. None were mentioned here, but there will be times when the underlying tables need to be exposed to the world (like data transfer utilities) while in other cases one might be better off with an HTTPS, gRPC, or GraphQL client.
Coincidentally, I watched a short video that talks about how having an API is necessary, but not sufficient. I’ve made most if not all of these mistakes.
