create dashboards using apex 18.1

Rads R
Rads R used Ask the Experts™
on
Hi APEX masters,

We are creating a DB portal with all information related to the databases . And would need ideas on creating dashboards in apex 18.1, please  suggest some sample applications or screenshots.

Thanks in advance,
R
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Hi,

That's not an easy-to-answer question without knowing more about what you are planning to do. Dashboards could look completely different, depending on if you want charts or just reports. A good start usually is the sample application (e.g. https://apex.oracle.com/pls/apex/f?p=42:1902:::NO:::). Take a look at the section cards and charts. Usually that should fit you with everything you need to know to build a dashboard.

Best wishes
Markus
Most Valuable Expert 2011
Top Expert 2012

Commented:
What data do you have available?
Do you have OEM? If so, do you need a dashboard or does the grid control already give it to you?

Author

Commented:
Hi Markusld

Thanks for the link, will definitely check that.

R
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
Hi sdstuber,

As i mentioned earlier building a DB portal , and would need ideas to have dashboard page !! Apart from the below what else can be added on the dashboard, so that dba's would like to see the first thing about their databases.

We have pages for -

Long ops, no-bind sql, realtime, blocking sessions, performance, capacity, health check, inventory, alerts

Let me know your suggestions., which I can display as reports or charts on dashboard.

hope this helps.

Thanks,
R
Most Valuable Expert 2011
Top Expert 2012
Commented:
Obviously any of those "could" be a report.  If you can make a sql statement to return any of those, then you can put the results into a report - that doesn't mean you should though.

A Dashboard should contain actionable information.

So, "no-bind sql" - if you have a report that shows all of the statements that are not using binds, or a chart that counts them for each database, will or can anyone do anything with that information?  If you have a fleet of 3rd party applications, having a chart that lists their failings likely won't produce much unless you can leverage your SLA.

Be careful with making reports of sql statements, because they can expose private data, especially if the application doesn't use binds.

Blocking sessions, you can make a report, or a chart, or both.  I've generated trees before to show lock hierarchies.
Generally though, these are not as helpful as you might expect as some locking can be expected in many applications without indicating a problem.

Performance - I would recommend using OEM's charts and tools first.  I understand in a previous question you said you were asked to write your own tool instead of using OEM.   - I've been down that path before, the better approach, both technically and professionally would be to push back to your management that the tools they are asking for are already available.  If you can't tell your management that they are heading down the wrong path, then that means they don't respect your opinion - which is not only demeaning to you, but it also brings into question their managerial skills if they build a team of people who's expertise is not heeded.

What I would suggest is using OEM as a base, and then augmenting it where needed.
For instance, I tied OEM into our ticketing and inventory system.  This allows for correlating user requests with specific OEM targets (databases and/or servers.)  Once I had the correlations, building reports or charts on them was easy.

I created a system-wide "dashboard" of db versions and platforms - (i.e. how many 11g,12c,18c on each OS platform) this shows our upgrade/patching status as well as showing overall storage trends.  You could generate these in OEM, but it was easier to produce the visualizations we were looking for in APEX.

If someone is asking you to build a dashboard but has given you no requirements as to what information you are supposed to expose, then simply generate a blank page.  It'll be easy, secure, and fullfill your requirements.

It should also help illustrate that asking for information without being told "which" information is rather silly.

Unless you're just looking for practice, don't build a dashboard of things you "can" gather,  build a dashboard of things that target value opportunities to your department and/or company.  In other words - you (or your management) must identify your own KPIs and then go build or buy a tool that tracks and reports them.
Most Valuable Expert 2011
Top Expert 2012
Commented:
I will throw out an addendum to my previous response - there can be value in simply trying things.

I got started in APEX development (back when it was still called HTMLDB) doing almost exactly what you're trying to do now.
A coworker and I spent a few weeks generating lots of different reports and charts mostly to learn how to do it.  We picked our data sources simply by what the two of us though was interesting.  Eventually some other people started making requests and that formed the basis of an application that ran for well over a decade.  - The vast majority of it was completely ignored though because our exploratory and learning exercises weren't useful to others.

When APEX 5 came out, I retired the old application and consolidated all of the information that our users actually touched into a new single summary page that pulled from the OEM repository as its data source.

So - if you really have no firm requirements, and you really don't know what to put on your dashboard, then just try whatever comes to mind that you think you can be some kind of value, either intrinsically valuable to others, or educationally to you and the other developers.

If your management is giving you little or no direction, then ask your DBAs, your system admins, other developers, your project managers, your manager's manager, etc what they think of your application.  Get feedback and requests, and head in that direction.  Either you'll find there is zero interest at all and the project can be closed down, or it'll gather steam with these various user groups seeking the information they will find valuable.

Author

Commented:
Hi sdstuber,

This is really helpful, will do check with my co-workers. Thanks a lot for taking time to explain so much in detail.

Really appreciate it.

Thanks,
R

Author

Commented:
Thanks a lot.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial