- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
The Yokohama release brought with it a raft of new in instance capabilities for our impact customers.
For me, one in particular stands out as something many customers would want to take a look at straight away: Impact Platform Health.
If your organisation has Impact, then you'll most likely already be familiar with the health information available in the Impact Digital Experience (IDE). The results of scans of the configuration of your instances, summarise into a scorecard describing the health. You'll might even be running health initiatives / accelerators to understand and get some insight into these findings from your Platform Architect.
A common request I have heard from customers is how configuration can be validated whilst in flight, before it gets anywhere near production. It's Impact Platform Health that offers an answer here.
So lets just dive right in, starting with the install. The plugin you want is "Impact".
It has a raft of dependencies which will in a real environment require review and proper consideration. One of the dependencies is Impact Health, and for the purposes of this article - that's what I want.
That's it. Done. All ready to use. This is the fun bit, I get to put a few of the things I know and regularly advise against as poor practice to use. Lets build ourselves a truly awful business rule!
First, I create a new local update set and make it current
Now we create our business rule. Because I use this instance for quite a few things, I am putting a condition in it that means it doesn't actually ever run. An incident cannot ever have a CI field with two different CIs in it.
And a few lines of code, that I am hoping the new scanner really does not appreciate.
Now, lets navigate back to our update set. We have new related lists for proactive code check results and findings and a proactive code check UI Action.
I run the check, which takes just 2 seconds
And then go to the results...
We can see that the scan has found 5 potential issues. Unnecessary dot walking, detecting hard-coded sys_ids, our daft current.update(), a constant used in a message string and the logging used (gs.log).
You can also sync information with a prod instance for analytics purposes, analysing common findings, analysing performance over time, etc.
A full list of the check in the proactive suite can be found here.
- 605 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.