First of all, it is important to understand that even servers with many CPUs and huge computing capacity and memory size may have performance issues. JDE allows up to hundreds of paralel users and each of them needs a little bit of server’s CPU as each user’s action has impact on database (reads or writes of records) which takes some time. Moreover, on each system there are hundreds of UBEs (reports) that need to be run daily to perform data manipulations etc. All these small requirements may result in heavy workload of local network and servers.

How to prevent performance issues caused by the development: Each developer should develop applications that both follow business requirements but are efficient. So the prevention is the best solution of the performance issues. However it very often happens that either developers are not experienced enough or they underestimate impact of their programs. In such a case their programs are inefficient, slow and may have serious impact on other processes as well. As a result the whole system is getting slower and an action is needed.

 How to make the system faster: To make the system faster, it is necessary to identify the biggest performance issues. At the beginning we may start with slow UBEs (reports) but the question is how to find out if a program can be faster?? We have two options – either we can ask a developer to review the program completely which may take from several hours to several days (for complicated programs) with doubtful results (because it is hard to say the impact of different pieces of logic). Or we can use a tool that will identify the performance problems for us. JdeAnalyzer uses the fact that EnterpriseOne can generate detail log („jdedebug.log“) with information about more or less any action that happens in any program (including all SQL statements, cache operations, function calls etc). Based on this file JdeAnalyzer can exactly calculate the CPU consumtion of all the business functions and SQL statements executed during the processing. Based on this information a developer can easily find the place(s) in the code with highest impact on performance and suggest/perform improvement.

What kind of performance issues are the most typical:

1. missing index for an SQL statement
2. incorrectly built SQL statement (especially in case of joins, wrong combination of selection and sequencing etc.)
3. executing the same function or SQL too many times with the same parameters (typically fetching from UDC)
4. incorrect program looping (bug in logic that has no impact on results but on performance)
5. generating records to work files that are not needed (usually a conceptual problem, the records are later deleted)
6. selecting too many fields from the database
7. updating the same record several times
8. incorrect passing of parameters to a UBE or function (as a result it selects too many records to process)
9. reprocessing the same records many times
10. and many others

 What are other benefit of using JDE Analyzer:

1. quality assurance, during analysis we often find logical problems as well
2. pressure on better development (if developers know that their programs are analyzed, they develop more responsibly)
3. verification of supplier abilities – a good JDE supplier provides good services with highly professional developers that don’t cause performance issues

How difficult is to use the tool: using the tool is simple however interpreting the results properly and suggesting the right improvements is a work for a very experienced developer with deep knowledge of SQL and databases and with excellent knowledge of EnterpriseOne.

 Please find attached example on how the result from my program looks like. It is not difficult to understand. In this simple example the main SQL statement took over 14 secs to return the first record which was almost 20% of the whole processing time. The biggest impact on performance was caused by function GetUDC that was called 3904 times (you may also see that this function reads from F0005D which took 15%). As a solution in this case we removed 3902 calls of GetUDC and called it only twice which made the whole report 2 times faster, then we optimized the main SQL statement so in the end the report was almost 3 times faster then before.

SQL STATEMENTS:
===============

SQL Statement: SELECT FROM CRPDTA/F0901 T0,CRPDTA/F0911 T1,CRPDTA/F0006 T
Calls: 1
Time:  14.61 sec    14.611 sec/call    19.8%
Recs: 1 fetched / 0 not found
From: _main_

SQL Statement: SELECT FROM CRPCTL/F0005D
Calls: 3904
Time:  11.32 sec     0.003 sec/call    15.3%
Recs: 1330 fetched / 2574 not found
From: GetUDC

SQL Statement: SELECT FROM CRPDTA/F0006D
Calls: 488
Time:   1.71 sec     0.004 sec/call     2.3%
Recs: 0 fetched / 488 not found
From: F0006DGetBusinessUnitTranslation

SQL Statement: SELECT FROM CRPDTA/F7611B
Calls: 240
Time:   3.49 sec     0.015 sec/call     4.7%
Recs: 204 fetched / 36 not found
From: _main_

SQL Statement: SELECT FROM CRPDTA/F4111
Calls: 36
Time:   1.64 sec     0.046 sec/call     2.2%
Recs: 36 fetched / 0 not found
From: _main_


FUNCTIONS:
==========

Function: GetUDC
Levels: 4-4
Calls: 3904
Time:  37.56 sec     0.010 sec/call    50.9%
Net:  37.56 sec     0.010 sec/call    50.9%

Function: CheckforAccountExistenceF0901
Levels: 4-4
Calls: 488
Time:   4.23 sec     0.009 sec/call     5.7%
Net:   4.23 sec     0.009 sec/call     5.7%

Function: F0006DGetBusinessUnitTranslation
Levels: 4-4
Calls: 488
Time:   3.30 sec     0.007 sec/call     4.5%
Net:   3.30 sec     0.007 sec/call     4.5%


Total processing time: 74 sec

JDExtract is an external program that can read specifications of EnterpriseOne objects and export them to text files. Unlike standard ER print, this tool supports tables, views, data structures, data dictionary items and UDCs apart from reports and applications. The exported ERs contain more information than the standard ER print, for example the aliases of variables, used indexes of table I/O, object and data structure names for BSFN calls and much more.

• The following list mentions what major types of information are exported for each object type:
• TBLE - list of table columns incl. their data types, list of indexes, ERs
• BSVW - list of tables, joins and columns
• DSTR - list of variables with data types, I/O flags
• PO DSTR - list of variables with data types, all comments
• APPL - application properties, forms with properties, form controls with data types and properties, ERs
• UBE - report properties, sections with properties, selections and sequencings, report variables and constants with properties, ERs
• Version - main information about version, version overrides
• DD - information about DD items
• UDC - settings and all the values

The extract can be run by objects, OMW projects or other criteria. Not only the program exports the Event Rules but it can also identify several types of issues in the Event Rules, these are clearly marked in the code. Also user can define custom alerts using search strings.

JDE ROCKET provides several tools that are missing in Oracle EnterpriseOne installations. These tools significantly improve the performance of developers and allow to decrease the costs for implementation or upgrade.

Copy NER

In OMW (Object Management Workbench) a developer can copy many different types of objects but not NERs. Sometimes, this would be extremely useful but there is no workaround. JDE ROCKET provides a simple solution - just specify the source and the target object name and function name and the NER will be copied in a few seconds. As a target you may specify a brand new object name as well as existing NER - in such a case the tool will append the copied function into the object.

Copy APPL or UBE Event Rules to NER
Have you ever developed a complex logic in an application or a report and later realized that

the performance is not as good as expected
the same logic needs to be reused elsewhere
the logic in the standard object is overwritten by an applied ESU/ASU
There is an easy solution - transfer the logic to a NER. Specify the object name, the Event Rule with the starting and ending line number and the target NER. After copying the logic the work is almost done, you only need to remove the logic from the APPL or UBE, add the function call and review the variables in NER.

JDEDEBUG.LOG viewer
Do you need to browse the jdedebug.log file but having difficulties with its size or understanding the content? Try the integrated log viewer, which provides the following:

the content is available immediately after opening the file, you don't have to wait to get it open
important keywords are highlighted, the highligting is fully customizable
provides special information on BSFN calls (such as changes in DS parameters etc)