About Me

My photo
I work for Fusion5 Australia . Connect with me on linked in here . I'm raising money for a good cause at the moment, follow donate to leukemia foundation

Friday, 24 July 2015

More on RTE and the fix for yesterdays problem

An update on this.

To fix, you generally need to choose a unique net listener port for the RTE net listener and then change the RTE OCM’s to point to that port.  You then need to reset the OCM cache for the kernels.

To change the service entry port

, I goto P90701A

image

From here choose the Server Map’s and System’s for the machines that will need to change (anything that is going to do an RTE lookup).  Then change the RTE mapping to the correct port.

For some reason I had to delete the old entries and add new ones, could not make inactive and copy…

Secondly, the cache reset to the network kernels start looking to the right RTE server for message delivery.

To reset the cache From WSJ, goto form advanced choose the server from the list below

image

Choose the server and then

image

Choose the reset cache row exit

Then the cache that you want to reset

image

All done, messages should go to the right port for RTE and everything will start to behave nicely.

Thursday, 23 July 2015

RTE port mapping, the wrong and right way

Interoperability is becoming more and more important and RTE is a great way of getting events out of JDE and into other systems.

Are you finding JDE locking up when RTE messages are being sent out of the system?

When configuring RTE, please remember:

  • The WLS listen port is the port that external systems will come in a pull messages off the queue.  This is NOT the port that JD Edwards talks to.  This is NOT the port that you configure in OCM for the active RTE service record.
  • The JDENET Listen port must be the SAME as the port you put in the OCM’s for the RTE

imageimage


Note that you may get lucky and messages will be delivered, but this is because they are “pulled” by the RTE code from F90710, not pushed by the network kernels via the call object kernels.

Note also that you’ll see things like this in your error log for jdenet_n:


1400/9228 MAIN_THREAD                      
Thu Jul 23 13:27:58.282000
NETFLOW.C1032
1400 (pid) in routeOutgoingQueue(), unable to send message: sd=-1, msgId=72066, msgHost=10.200.11.121, msgPort=8085, sendingHost=10.200.11.15, msgType=15501, msgRange=28, krnlName=APP SERVER KERNEL, reqNet=0, resNet=0, reqKrnl=14008, resKrnl=0, msgFlags=0.

1400/9228 MAIN_THREAD                      
Thu Jul 23 13:30:57.621000
NETFLOW.C1032
1400 (pid) in routeOutgoingQueue(), unable to send message: sd=-1, msgId=72132, msgHost=10.200.11.121, msgPort=8085, sendingHost=10.200.11.15, msgType=15501, msgRange=28, krnlName=APP SERVER KERNEL, reqNet=0, resNet=0, reqKrnl=14008, resKrnl=0, msgFlags=0.

1400/9228 MAIN_THREAD                      
Thu Jul 23 13:32:10.052000
NETFLOW.C1032
1400 (pid) in routeOutgoingQueue(), unable to send message: sd=-1, msgId=72193, msgHost=10.200.11.121, msgPort=8085, sendingHost=10.200.11.15, msgType=15501, msgRange=28, krnlName=APP SERVER KERNEL, reqNet=0, resNet=0, reqKrnl=14008, resKrnl=0, msgFlags=0.

1400/9228 MAIN_THREAD                      
Thu Jul 23 13:36:37.048000
NETFLOW.C1032
1400 (pid) in routeOutgoingQueue(), unable to send message: sd=-1, msgId=72264, msgHost=10.200.11.121, msgPort=8085, sendingHost=10.200.11.15, msgType=15501, msgRange=28, krnlName=APP SERVER KERNEL, reqNet=0, resNet=0, reqKrnl=14008, resKrnl=0, msgFlags=0.

1400/9228 MAIN_THREAD                      
Thu Jul 23 14:28:20.298000
NETFLOW.C1032
1400 (pid) in routeOutgoingQueue(), unable to send message: sd=-1, msgId=72624, msgHost=10.200.11.121, msgPort=8085, sendingHost=10.200.11.15, msgType=15501, msgRange=28, krnlName=APP SERVER KERNEL, reqNet=0, resNet=0, reqKrnl=14008, resKrnl=0, msgFlags=0.

1400/9228 MAIN_THREAD                      
Thu Jul 23 14:29:42.775000
NETFLOW.C1032
1400 (pid) in routeOutgoingQueue(), unable to send message: sd=-1, msgId=72687, msgHost=10.200.11.121, msgPort=8085, sendingHost=10.200.11.15, msgType=15501, msgRange=28, krnlName=APP SERVER KERNEL, reqNet=0, resNet=0, reqKrnl=14008, resKrnl=0, msgFlags=0.


One crazy thing is that this causes a FULL SYSTEM lockup.  While the jdenet kernel is waiting for the TCP confirmation – everything stops!!!  Crykie – that’s not good.

Please be careful with your port specifications when using RTE!

Wednesday, 15 July 2015

Performance history queries, release 2

I’ve found a bit of a mistake in one of my historical posts, so it’s time to make it right.

SELECT JCPID as INNERPID, JCVERS as INNERVERS, simd || vrjd, 
count(1) as INNERCOUNT,
Avg(86400*(JCETDTIM-JCSTDTIM)) as INNERAVERAGE,
min(86400*(JCETDTIM-JCSTDTIM)) AS INNERMIN,
max(86400*(JCETDTIM-JCSTDTIM)) AS INNERMAX
from svm910.f986114,ol910.f9860, pd910.f983051
where trim(jcpid) = trim(siobnm) and trim(jcvers) = trim (vrvers) and trim(jcpid) = trim (vrpid)
and JCETDTIM < TO_DATE('01072015','DDMMYYYY') and JCETDTIM > TO_DATE('01062015', 'DDMMYYYY')
group by jcpid, JCVERS, simd || vrjd ;

Above is the new improved code, but the difference is subtle (just like the b in subtle).  I’m using date comparison, not string comparison of the dates, which is more accurate. My SQL would have been correct if I put YYYYMMDD, because then then string comparison is accurate for dates – but because I was putting the day first – things were a little “all over the shop”.


The old code was here:


http://shannonscncjdeblog.blogspot.co.nz/2015/06/nice-ube-batch-performance-summary.html

Thursday, 2 July 2015

Quick “did you know” post

I was using a development workstation the other day, this DID have jDeveloper installed, but did not have SQLDeveloper…  How that occurred – I will never know.  But the really cool thing I worked out (quite randomly) was that I could evoke a JDeveloper version of SQL and use SQL work sheets from JDeveloper.  This was a really nice find.  It also helps me when I’m using JDeveloper on my mac.

image

To view your connection details, goto window –> databases

image

And see

image

This is really neat.  Very easy to set up connection strings too, of course, because it’s oracle – very easy to find jdbc’s drivers for oracle.

The reason I’m doing this is long and convoluted, I’ll probably post some more details of it soon. 

We are developing a piece of software that will enable you to print attachments as well as reports from JDE.  So, for example, if you wanted to print today’s work orders and the attachments for those work orders, then you could do this automatically.  Our software will find the WO# in the BIP output (or standard PDF) and then query the F00165, find the relevant attachments – download them if necessary and then print them using the appropriate printing software.  WOW – how cool is that!  It’ll also print a cover sheet of the attachments and what was printed. 

We are developing this for the use-case of work orders, but we can see that this is going to be popular for many different business scenarios (ITEM’s / sales orders / addresses etc).

We needed to spend some time ripping the XML data from the F95630 table for the reports that have been run so that we could reverse engineer the data coming out for each report.  There was some slightly tricky stuff to make that visible, but nothing has stopped us so far.