Debug client only NER

[BOster]

Is there any way to use the ER debugger to debug a Client Only NER called from an APPL in an HTML client (interpreted NER) since the NER ER code is effectively what is running in that situation and NOT the generated C code?

I have an HTML version of MDDebug for this, but it is a PIA to go in and put those calls everywhere where I would normally put a break point in the ER debugger.

 

[BOster]

Not really an answer to my original question, more of an update to my unstated problem. I had made a change to a client only NER and wasn't seeing the change. Bounced my local JAS instance, nothing. I had to manually java gen the NER in order for my changes to be seen. Apparently once the object is loaded the auto-java gen doesn't work so well for changes to client only NERs.

Still would like to know if it is possible to debug a client only NER using the ER debugger.

 

[DBohner-(db)]

B.

To my knowledge, the act of saving the NER creates the C Code. Compiling the NER compiles the C Code. Objects that use the NER are actually hitting the Compiled C Object / DLL ...

NER/TER are Compiled Code. You have to use the C Debugger to debug them.

You did save the NER, then compile it - right?

The NER is C - treat it just like you would any other C object...

(db)

 

[peterbruce]

Brian,

Have you tried to do that? If so, what did you do and what were your results? If not, to use an Australian phrase: "'ave a go y' mug!"

Is it possible to load debug information for a NER the same way as it's done for an APPL? I am curious as to the answer, but have no need at the moment. All the best for sorting this one out.

 

[craig_welton]

An interpretive NER, or client only NER, is not compiled code. The ER is "interpreted" like an application event.

I have not been able to establish any breakpoints since you can't bring up the NER object in the debugger. Had to use the jas debug log and similar HTML MDDebug tricks.

Sounds like a tools enhancement request.

 

[DBohner-(db)]

Craig / Brian,

Can you forward me an example of a native JDE "Client Only" NER?

I've created NERs in the past that were defined to work only from a Fat Client (client only) - and I still had to compile and debug through C. I guess this is something I've not experienced.

I guess I haven't touched an Interpretive NER before.
(db)

 

[DBohner-(db)]

To reiterate my understanding / misunderstanding...

NERs are Business Functions that are created using Interpretive Event Rule Logic. You define the logic within the NER using Standard ER syntax ...AND... when you push the SAVE button, the logic is rewritten as native .C and .H into your Source and Include folders.

You Must compile a NER into a DLL

When a NER is marked as Client Only - it simply means an expectation that 'functionality' is meant to be run on a FAT, or Windows client, only (that it contains logic or functionality that is specific to Windows).

To Debug a NER - you point Visual Studio to the C Code and turn on your break points as you would a native C Function. If you have a NER Object named N55Code - you will find an N55Code.C and an N55Code.h in their respective folders. You point Visual Studio to the C Code - you do not use the ER Debugger.

Is there something in the NER educational track that I completely missed?

(db)

 

[DBohner-(db)]

Ah - something new:

In Document:
E1: BSFN: Frequently Asked Questions for How to Find, Design and Debug of BSFN [ID 632000.1]


"...The only exception to this rule for client-only business functions is a Named Event Rule marked client-only solely because it has a form interconnect. When this type of NER is generated, the tool generates Java classes instead of C code for this function. In this context, these type of NERs are called Interpretive NERs. Interpretive NERs have the following guidelines:
- Interpretive NER can only be called from an application ER or from another interpretive NER.
- Interpretive NERs should not be called from UBEs, client/server business functions or server only business functions.
- The NER must be defined as client-only if it contains form interconnects. The tool uses the client-only designation to determine if Interpretive NER should be used."

The requirement for an 'Interpretive / java' NER is that it must have a Form Interconnect and be marked 'client only' - right?

That said - I'm going to guess that you would debug the 'Interpretive' NER (one that has a Form Interconnect) using Java?


Old dog, new trick....

(db)

Addendum:
Review - E1: BSFN: Frequently Asked Questions on Batch Control Processing and Related Business Functions in EnterpriseOne [ID 1317478.1]

 

[Remo Williams]

thanx, interesting stuff. as BOster recently said: "I learn something new every day"

 

[BOster]

[ QUOTE ]
Ah - something new:

In Document:
E1: BSFN: Frequently Asked Questions for How to Find, Design and Debug of BSFN [ID 632000.1]


"...The only exception to this rule for client-only business functions is a Named Event Rule marked client-only solely because it has a form interconnect. When this type of NER is generated, the tool generates Java classes instead of C code for this function. In this context, these type of NERs are called Interpretive NERs. Interpretive NERs have the following guidelines:
- Interpretive NER can only be called from an application ER or from another interpretive NER.
- Interpretive NERs should not be called from UBEs, client/server business functions or server only business functions.
- The NER must be defined as client-only if it contains form interconnects. The tool uses the client-only designation to determine if Interpretive NER should be used."

The requirement for an 'Interpretive / java' NER is that it must have a Form Interconnect and be marked 'client only' - right?

That said - I'm going to guess that you would debug the 'Interpretive' NER (one that has a Form Interconnect) using Java?


[/ QUOTE ]


Yup, this is the only reason I know of where you have to use an NER (form interconnect) as opposed to a C BSFN. I use them a lot for view dispatchers instead of direct form interconnects. It allows me to do some small intermediate logic and will allow me to easily change the called form in one place instead of going to every place where that form might be called if I ever need to change which form is used.

It is interesting that it says it generates Java classes. I just assumed the APPL run time engine simply loaded the ER code and interpreted it just like it would the ER code in an APPL event. Problem is, is that when you try to step into it in the ER debugger, the ER debugger simply sees it as just another BSFN when its really not.

BTW, I have found (at least on my tools release) that if you make a change to an "Interpretive NER" you have to stop your local JAS server and manually java gen the NER or your changes will not take effect. In other words, it doesn't dynamically java gen the object when loading after you make a change like it does for an APPL.

 

[DBohner-(db)]

So, the underlying question still remains - how to debug the monster.

Do we treat it like a Business Service - and debug it through that path, using jDeveloper? I'll send a ping/plea out the Chris Walsh's team - and request the steps.

Thanks for learning the old dog a new fetch.

(db)

 

[craig_welton]

I think the quote about it generating java is misleading. The NER is interpreted like any other ER event, which is read from serialized objects. We don't debug applications at the java level, java is language used to interpret the serialized objects.
Again, I think the debugger needs the ability to host interpretive NERs.

 

[BOster]

Agreed on all accounts. I really think the APPL engine just loads the ER code like it would for an APPL event, sort of like an #include statement for ER code and executes it. There is no reason why the debugger should't be able to step into that ER code and debug it just like any other APPL ER code. There are probably so few "Interprted NERs" that the demand has not been high enough for Oracle to do anything about it.

 

[DBohner-(db)]

Bad news, for now...

One of the listers in the LinkedIn group, JDEResearch, opened a support ticket - asking how to debug NERs.

B.A. Comments after their response:
...according to Oracle, these cannot be debugged. They recommend using the B0900102 to write messages to the JDE log if you need to troubleshoot one of these NERs....

Sounds like an enhancement request...

(db)

 

[Scott Beebe]

I was kind of ignoring this thread. But, it finally peaked my interest. I just read the entire thread and here are my thoughts. There are many client only functions that get used for admin/cnc purposes because they contain platform specific code, normally specific to windows. While I haven't tested to confirm I find it highly unlikely that these type of functions would get generated as interpreted code. But, I guess on the other hand, the CNC guy doesn't use the web client at all does he, so maybe nobody knows if this is the case. It makes more sense to me that platform specific code would run as any other function through a call to a DLL.

If this is the case then maybe there are some smarts in the system to know when it can create the interpreted version of the code for the web client and when to use the DLL instead. If this is what happens, could we not modify our client only function to temporarily call a function that we know is platform dependent so it will get called via a DLL?

Did this make sense? I am stretching, but wondering if this has been tried.

 

[BOster]

As far as I know, when you call a client only NER from an APPL running in an HTML client it always gets called as an interpreted NER. And if you think about it that is the ONLY way it could call it. To call the actual compiled C code the JAS server would need to load the DLL, get the proc address, call the function within the JDE session context, etc.... pretty much everything an Enterprise server does...

The platform specific stuff you are talking about is usually in C BSFNs, not NERs and would be called from a Win32 client, not a JAS client. Additionally this platform specific stuff may often involve launching some sort of Windows dialog like a file open dialog or some other Windows based application... stuff that cant happen on a server enterprise or JAS which is why the BSFN is probably client only to begin with.

I go back to the fact that the ONLY reason I know of to make an NER client only is if it contains form interconnects and the only reason you have to use an NER as opposed to a C BSFN is if you need form interconnects.

 

[craig_welton]

[ QUOTE ]
I go back to the fact that the ONLY reason I know of to make an NER client only is if it contains form interconnects and the only reason you have to use an NER as opposed to a C BSFN is if you need form interconnects.


[/ QUOTE ]

Exactly. That is the point of an Interpretive NER. A form interconnect cannot be performed by a call object kernel. Note, an interpretive NER CAN call another BSFN that will execute on a call object kernel. Just like an APPL event executing a BSFN.