Named Event Rule API

[nkuebelbeck]

I reading through a named event rule c code (not exactly fun) when I came across some API calls I've never seen before for table IO in JDE C.

RTK_CER_FIOOpen
RTK_CER_FIOSelectInit

etc etc

They are defined in JDEKPRTO.h

Here is one prototype

KRNL_RTN( ID ) RTK_CER_FIOOpen(HUSER hUser , NID szTable , ID idIndex , short nType , HREQUEST* pReq);

here is the API I always use

JDEDB_RESULT JDB_OpenTable(HUSER hUser, NID szTable, ID idIndex, NID *lpColSelect, unsigned short nNumCols, char * szOverrideDS, HREQUEST * hRequest);

Are these wrappers around existing JDEBASE for NER? Something else?

Should I just forget what I found and move on with the rest of my day?

 

[BOster]

Are these wrappers around existing JDEBASE for NER? Something else?

Should I just forget what I found and move on with the rest of my day?

Probably. I am guessing RTK_CER_FIOOpen simply calls JDB_OpenTable passing null for szOverrideDS (or some private implementation of JDB_OpenTable) and then throws an error with text substitution or something like that if it fails. You could always call it for a table that doesn't exist and see what it does... might save a few lines of code instead of having to throw your own error with text sub.

 

[Chan Rana]

I have found them in many C functions so its not limited to NERs. Looks like they came up with this API during HR etc. as i see they have used it in many recent new modules. There are many related APIs like RTK_CER_FIOSelectInit, RTK_CER_FIOSelect, RTK_CER_FIOClose etc restricted to some basic table i/o.

Chan

 

[nkuebelbeck]

I have found them in many C functions so its not limited to NERs. Looks like they came up with this API during HR etc. as i see they have used it in many recent new modules. There are many related APIs like RTK_CER_FIOSelectInit, RTK_CER_FIOSelect, RTK_CER_FIOClose etc restricted to some basic table i/o.

Chan

Should we be using the latest greatest? or do you think it's more like Brian explained, a wrapper.

 

[BOster]

Maybe find some more recent pristine C BSFNs and see what internal Oracle developers are using. Might be an indication of which way to go.

 

[Chan Rana]

Looks like this is way to go as most of the functions they have used in are all written in 2013.

 

[craig_welton]

Which functions are you seeing this in? I find RTK_CER_FIOSelectInit in a lot of B*.c functions but they are NERs that were named with B instead of a N. Or worse some kind of copy of a NER to a B. They are just wrappers on top of the JDB APIs, do we really need another layer?

 

[BOster]

My biggest concern would be if the RTK_CERxxxxx APIs were created simply to make C code generation from NER/TER easier they could always decide to change their NER C generation implementation to something different and completely do away with those API calls and if you have been using those API calls you might be in trouble.

However, they have to keep the JDB_xxxxx calls since there is millions of lines of existing C BSFN code that uses them.

 

[jdelisths]

They have to keep the JDB_ calls, as Brian stated. The risk in using the RTK_CER functions is that Oracle may decide to change the method signature for a future tools release. That will break your code, but it won't break theirs as NERs can be regenerated.

 

[nkuebelbeck]

good discussion. Thanks everyone.

Someone once told me the only problem abstract can't solve is the problem of abstraction.