Quantcast
Channel: Teradata Developer Exchange - Viewpoint
Viewing all 81 articles
Browse latest View live

Automated Statistics Management

$
0
0

Managing Teradata Optimizer statistics can be labor intensive and error prone. Many users struggle to know what columns and indexes to collect statistics on, how to detect and prevent statistics from becoming stale, and how to know if collected statistics are being used.

Enter AutoStats! Automated Statistics Management (or AutoStats for short) is a new feature in Teradata 14.10 that helps automate statistics collection and provides intelligence surrounding statistics management. Using the new “Stats Manager” portlet in Teradata Viewpoint 14.10, users can schedule jobs to collect statistics and analyze a system for missing, stale, and unused statistics. Join us for a demo of the new “Stats Manager” portlet in Teradata Viewpoint and learn what AutoStats can do for you! The session will include discussions on best practices and how AutoStats works behind the scenes.

Presenters:
Eric Scheie - Teradata Corporation
Louis Burger - Teradata Corporation

Training details
Course Number: 
51253
Training Format: 
Recorded webcast
Price: 
$195
Credit Hours: 
2
Channel: 

Performance Testing - When is it time for a System Tune Up?

$
0
0

How do you determine your system’s performance prior to the dreaded customer call asking why their queries are running longer?  What’s the impact to the business when the warehouse environment is under performing?

This presentation addresses best practices on performance testing and monitoring and the realistic actions that can be taken.  Performance baselines, benchmarks, workload queries, and canary queries are covered.  When/how to test are also described. Short term and long term ‘tune up’ performance ideas are given including capacity planning.

Note: This was a 2010 Partners Conference session, updated and re-recorded in 2014

Presenter: Jim Blair, Teradata Customer Briefing Team

Audience: 
Data Warehouse, Administrator, Data Warehouse Technical Specialist, Data Warehouse Project/Program Mgmt
Training details
Course Number: 
49658
Training Format: 
Recorded webcast
Price: 
$195
Credit Hours: 
1
Channel: 

What's New With Viewpoint 15.00 Shared Pages

$
0
0
Short teaser: 
The Shared Pages feature in Viewpoint has been updated to make it simpler and more intuitive.
Cover Image: 

The Shared Pages feature in Viewpoint has been updated to make it simpler and more intuitive. Now, if you want to create a template page to share with others or to ensure that new users are not greeted with a blank Home page, you can find everything you need in the new and improved Shared Pages admin portlet.

For anyone not familiar with the Shared Pages feature, it allows admin users to create template Viewpoint pages and have full control over the layout of portlets on the page and the settings and views within the portlets. You can allow users in a role to take a copy of a shared page and customize it, to view a read-only page that cannot be customized so you can ensure your users have a consistent view of data, and you can automatically add pages to the portal.

The main changes in the Shared Pages interface from the last release are:

  • Features and functions have been consolidated in one area – Now the Shared Pages admin portlet is a one stop shop for creating and managing shared pages
  • Removed banner messages that appeared to end users on portal pages – The message banners that took up valuable screen real estate for little value have been eliminated
  • Permission to administer shared pages is now a normal portlet permission – It is no longer a 'special' permission that lives in a different location from other permissions

The Making of a Shared Page

To get started, ensure the Shared Pages portlet is enabled and that you belong to a role that has permission to use the portlet.

Upon opening the portlet, you see a list of all of the shared pages that have been created and some useful data points for each.

Page Properties

When you click the Add Shared Page button you are presented with some options for how the page should be applied. Normally, shared pages are editable and can be added or removed at any time.

Assign to Role

This is how you choose who can use the page. After you create the page, you cannot change the role since different roles can have very different access rights so switching roles could get messy.

Enable page

This specifies whether or not the page is accessible to users. Remember that as soon as you click Create, the page is generated. If you don't want end users to see that page until after you have added and edited the portlets, do not enable the page until you are happy with the end result.

Show this page the first time a user logs in

This option helps new Viewpoint users by automatically displaying a useful portal page rather than a blank page.

Read-only

This ensures that everyone who adds the shared page to the portal will see the same portlets in the same configuration.

Mandatory

This variant of a read-only page that is automatically added for everyone in the target role and cannot be removed.

Edit the Page

Now that Viewpoint knows the target role and its associated permissions, you can build a shared page and see how it will look to users. The page edit screen looks nearly identical to a normal page.


In the first step, you already configured the Page Properties so the next step is to add portlets to the page. The Add Content interface allows you to add only the portlets available to the target role. This removes some of the confusion of the previous release where you could add any portlet but it might not appear to the user.

When customizing the shared page, 'Edit and Preview' is the normal mode and ensures you see exactly which features and functions are available to users in the target role. It is recommended that you do most page configuration in the preview mode and that you verify the shared page in that mode before saving.

The gear icons allow you to configure additional settings that might not be available to the target role such as the ability to configure which table columns appear, select a target system, and configure portlet Settings (previously known as Preferences).

When you are happy with your creation, ensure the page is enabled and click Save; the new page will be available to all users of the target role.

The Taking of a Shared Page

After the page has been created, it can be added (assuming it is a normal or read-only page) using the Add Page menu at the top of the portal (the plus icon to the right of the page tabs). Mandatory pages do not appear in the list because they are added automatically for all users in the role.

 

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

Unified Data Architecture Monitoring & Management

$
0
0

The Unified Data Architecture enables Teradata, Aster and Hadoop to deliver unparalleled value.

Teradata Viewpoint, Studio, Table Operators, and the Unity product suite provide enabling technologies for connectivity, monitoring, and management for all these systems. This presentation will highlight the features and capabilities of these client enabling solutions.

Presenter: Gary Ryback - Teradata Corporation

Training details
Course Number: 
51539
Training Format: 
Recorded webcast
Price: 
$195
Credit Hours: 
2
Channel: 

Introduction to TASM/Workload Management Portlets (SLES11)

$
0
0

This session will provide an overview and demonstration of the TASM portlets and TASM feature functionalities, focusing primarily on the new features introduced in Teradata 14.0 SLES 10 and SLES 11.

It will demonstrate how to use the Workload Designer portlet to configure TASM rule sets that exercise these features. It will also highlight where these features are available in the Workload Monitor portlet while monitoring workloads on a Teradata system. This session will cover in depth the TASM portlet changes that support the new workload management methods introduced in Teradata 14.0 SLES 11.

This presentation was updated and re-recorded in October 2014.

Presenter: Betsy Cherian, Engineering Manager, Viewpoint Core - Teradata Corporation

Audience: 
Data Warehouse Administrator, Data Warehouse Application Specialist
Training details
Course Number: 
50178
Training Format: 
Recorded webcast
Price: 
$195
Credit Hours: 
1
Channel: 

Introduction to Teradata Active System Management (TASM)

$
0
0
Course Number: 
39365
Training Format: 
Recorded webcast

TASM gives customers the ability to manage Teradata resource usage and performance on platforms executing diverse types of work.

This session discusses how to get started using TASM, as well as what workload management rules are available within TASM to control concurrency, to determine what queries are allowed to run, or to differentiate the priorities of active workloads. Examples of commonly used options from current TASM users are shared.

Key Points

  • Overview of TASM
  • TASM Features
  • Frequently used TASM options 

Presenter: Carrie Ballinger, Sr. Technical Consultant – Teradata Corporation

Audience: 
DataWarehouse Architects, DataWarehouse System Administrators, DBAs, Enterprise or IT Architects
Price: 
$195
Credit Hours: 
1
Channel: 

Ad Hoc Workloads and Business Performance SLAs

$
0
0
Course Number: 
47902
Training Format: 
Recorded webcast

How do you determine you’re who gets priority when every user thinks their work should come 1st? What’s the impact to the business when the warehouse environment is thought to be under performing? Or is it just that one user? This presentation will address best practices in establishing workload SLAs, both tactical and strategic, in an Ad Hoc environment and how to engage the business users in determining priority. Included will be realistic testing methods, what testing can and should be performed prior to Query implementation. Query SLAs, both tactical and strategic, will be discussed, as will methodologies for gaining consensus on priority. Ongoing SLA monitoring, tracking and reporting will also be discussed.

Updated and re-recorded in January 2015.

Presenter: Jim Blair, Data Warehouse Consultant – Teradata Corporation

 

Audience: 
Data Warehouse Administrators, Data Warehouse Business Users, Data Warehouse Technical Specialists
Price: 
$195
Credit Hours: 
1
Channel: 

Teradata Data Lab (15.10) Overview

$
0
0
Course Number: 
53411
Training Format: 
Recorded webcast

This course provides an overview of the Data Lab product concepts and value proposition and how it applies to DBAs, Power Users, and the business community.

It is comprised of both a slide presentation as well as a live product demonstration. The demonstration will show the new and improved look & feel introduced with the Data Lab 15.10 release. The course will also review how other Teradata technologies can interact with Teradata Data Lab extending the self-service aspects of data analytics and exploration.

Presenter: Gary Ryback, Product Management Director - Teradata Corporation

Audience: 
This course is blended to apply to both the DBA / IT staff, power users, as well as the analytical business community.
Price: 
$195
Credit Hours: 
1
Channel: 

Teradata Data Lab 15.10 Release

$
0
0
Short teaser: 
Release article covering all the significant enhancements released with Data Lab 15.10.
Cover Image: 

Very pleased to announce the formal release of Teradata Data Lab 15.10 effective April 2015! Teradata Data Lab 15.10 is a very exciting release as it is a significant product evolution in feature functionality, navigation, performance and ease of use. The Data Lab Viewpoint interface has been combined into one redesigned double-wide portlet offering more information, context sensitive requests, and enhanced navigation. Read on to discover more about this new exciting Data Lab product release.

Data Lab Concept:

To review, the key concept around Teradata Data Lab is to stop moving production data out of production to feed analytical islands, such as spread marts or data marts. Instead, move the analytical proofing data into a production intelligent sandbox environment where Data Lab provides production protection for the DBA while allowing self-service provisioning and governance capabilities desired by the analytical community. A much better approach in terms of data security, user efficiency, system resource usage, and proofing confidence to name just a few of the benefits.

Data Lab 15.10 Release Overview:

Here are the highlights of the Data Lab 15.10 Release:

See below for more details on all of these exciting new features.

The New Data Labs Portlet

With the Data Lab 15.10 release, the Data Labs portlet is now an all-inclusive, covering all functionality of the prior Data Lab release Lab Group Setup and Data Labs portlets. In addition to combining the two portlets, we have expanded the real estate of the portlet to allow for more column displays as well as improved navigation between lab groups, data labs, and tables. Within this new architecture, there are also performance improvements! Here's the new portlet look showing all three levels of Data Lab (lab groups, labs, and tables) in a single "Monitoring" view. 

There are a number of new columns for display across the lab group. lab, and table views, in particular at the lab group level. As a reminder, you select and configure your column preferences through the "Configure Columns" option in the upper right "Table Actions" pull down menu as highlighted above. Here are the available columns across the three levels:

In addition to the new format, we have added Situational Awareness for easy informational display and request creation / submission whether that is requesting a display of lab details or extending an existing lab. These new menus, triggered via the pull down in the left margin, are available at all three levels as shown below. The lab group or data lab creation is now done through the "+" in the blue left margin section headers for Lab Groups and Labs. Note that the Requests tab has been maintained so you can still generate and submit requests there as well. 

In the view above, you will also notice a new lab request option, that being "Reinstate Lab". Since the first Data Lab release, we have always offered expirations of labs driving the point that data labs should not be permanent. A lab that expires simply has the access permissions removed, so the underlying tables and data remain intact. In the past, if you wanted to transition an expired lab to be active again, access permissions had to be manually rebuilt. With Data Lab 15.10, the access permissions are captured as part of the expiration. The new Reinstate Lab now allows an easy automated way to reapply the expired permissions. This should make resurrecting expired labs much less painful. 

Data Lab 15.10 also now offers new owner and user/role access displays at both the lab group and lab levels. These displays are initiated through the View Lab Group Details and View Lab Details requests. Here are the resulting displays when these new request options are selected. Worth noting, to enable these new displays, there is a new lab group "Enable display of users and roles for the lab group and labs" toggle checkbox. Refer to the New Lab Group Features section of this article for the exact location of this checkbox.

Here are two views of the View Lab Group Details, the first showing the "General" lab group informational display and the other displaying the user / role access at the lab group level. The "Owners" display option would obviously display the Lab Group Owners listing. The View Lab Details shows very similar information but for the labs themselves.

 

New Lab Group Features

There are a number of new lab group features that have been realized in the Data Lab 15.10 release. Many of these were direct customer requests and we listened! So let's walk through these by looking at some of the setup steps in the refreshed "new look" lab group 6-steps setup wizard. 

Step #1 in setting up a lab group is to define the aspects of the lab group itself. For this step in Data Lab 15.10, you will see the new lab group description field which will assist users in those Data Lab installations where the number of lab groups is increasing. There is also a new database search capability when selecting the "Parent database" which makes it easier to navigate the Teradata system objects. This setup step is also where the new toggle checkbox for user / role displays is located. 

Step #2 in setting up a lab group is to define the settings and defaults related to the labs within this lab group. This step in particular has a number of customer requested additions. Hopefully it is not getting too busy. The first enhancement to mention is the configurable day settings for the number of day settings for expirations, deletions, and the new maximum cumulative life. The number of day selections in the past was limited to a specific pick list (i.e. 30, 60, 90 ...). This just didn't provide enough flexibility for all the different customer use cases. Although we didn't abandon the pick list due to its ease-of-use value, you can now manually enter whatever number of days you want. So the "99" days to expiration and "33" days to deletion in the screen shot below.

We have also added the "Remove no expiration option from requests" checkbox. Yet another customer request where those pesky users would ALWAYS select no expiration when requesting a lab extension. Those customers that believe labs should be temporary would never approve a "no expiration" extension request so why even offer it. So you no longer have to offer this extension request. Another checkbox addition in this setup step is the "Grant lab users CREATE TABLE privilege". This is for customers that don't allow users to create objects due to concerns around object ownership and grant access capability. So for those customers that require objects created in a different manner, through a stored procedure for instance, they can now implement Data Lab without object ownership concerns. 

The most significant addition in this step is "Request Limits". Request limits implement maximum setting controls for both the life and size of a data lab within this lab group. In the majority of cases, a data lab should be temporary and the new maximum cumulative life provides a secondary level of control. For instance, a lab owner continues to request lab extensions at an extension that is automatically approved. The request that exceeds the cumulative life will go for approval regardless of any automated approval settings. The same idea applies to the maximum size where the new automated approval logic is that certain size increases will be automatically approved but only to a certain limit, they then go for formal approval regardless. These new limits should help both DBAs and Lab Group Owners in managing lab groups and labs in their environment.

The other four steps (#3-#6) of the lab group setup wizard have not really changed in Data Lab 15.10 with one minor exception on step #6. Below is a quick review of these other steps and information on the minor addition to step #6.

  • Setup step #3: Owners - The description of this step is "Select which Viewpoint users and roles own the lab group." This assigns Lab Group Owners who are then enabled to approve and thus manage lab group requests within this lab group. Note this is a Viewpoint assignment so there is no actual additional Teradata permissions granted as part of this operation. Another point of confusion is Lab Group Owners are NOT enabled to create new or edit existing lab groups. 
  • Setup step #4: Private - The optional setup step is described as "Restrict which Teradata users and roles can access the lab group." So a private lab group is not only controlled from a visibility standpoint but also limited to what Teradata user and roles can be included in lab group requests, for instance an "Add User" request. 
  • Setup step #5: Default Users - Access within Data Lab can be at a lab group or lab level. So as the step description mentions "Select which Teradata users and roles have access to all labs in this lab group." This is access assignment at the lab group level. Note that access at the lab level is done during a new lab request or subsequent add user request.
  • Setup step #6: Approvers - The approvers step defines what requests at what thresholds are automatically approved or require approval and by whom it may be approved, either a lab owner or lab group owner. The step description describes this as "Set the thresholds and approver for each request type." There was one informative addition to this screen that being an informational notation for the lab default size setting (100MB in the graphic below). The reason we added this is to enforce compliance with the presented defaults in a add lab request. For the lab group below when a request for a new lab is generated, the size default presented is 100MB. The self-service auto-provisioning thinking here is that if the requester chooses the default or something smaller, than that should be a consideration for automatic approval. This simply saves from having to go back to step #2 and retrieve that lab setting.

Enhanced My Notifications:

My Notifications is a preference setting to allow you to manage your emails generated from the Data Lab product. The same as other Viewpoint preferences, this is located in the "Portlet menu" pull down in the upper right corner of the Data Labs portlet. This enhanced preferences now offer the following email configuration options:

Release Compatibility:

  • Teradata Data Lab 15.10 requires Teradata Viewpoint 15.10 and vice versa.
  • Teradata Data Lab 15.10 is supported with Teradata Database 15.10, 15.00, 14.10, 14.00, and 13.10 releases.
  • Teradata Data Lab is not currently supported with Teradata Aster or Hadoop but both are future roadmap considerations.

Thanks and let us know what you think of this most excellent Data Lab release.

 

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

Overview of Teradata Viewpoint 15.10

$
0
0
Short teaser: 
This article is the official release announcement for Teradata Viewpoint 15.10
Cover Image: 

This article is the official release announcement for Teradata Viewpoint 15.10 with an effective release date of April 9th 2015. In addition to providing support for various Teradata products, the Viewpoint 15.10 release offers two new strategic reporting portlets, Query Log and Application Queries.  

Summary

The primary themes of the Viewpoint 15.10 release are to enhance Teradata DB reporting capabilities and to support various products including Teradata Database 15.10. The highlights of the Viewpoint 15.10 release are:

Performance Reports

Two new portlets were added in Viewpoint 15.10 which support Teradata Database 14.10 and newer.  These portlets use data from Performance Data Collection and Reporting (PDCR) infrastructure.

Query Log

The Query Log portlet enables Teradata Database Administrators to view key reports based on the historical DBQL data in the PDCRDATA.DBQLogTbl_Hst table in Teradata Database. In the screenshot below, it shows that 4 applications or 3 users utilized the system named "paper" on May 18th 2015. Next to it the bar chart displays a visual representation of the numbers of queries that fall into each category for the selected metric. The chart provides details such as number queries that had single AMP, two AMP or all AMP steps or number of queries resulted in an error etc.. The trend chart next to the bar chart helps analyze key performance indicators, aggregated by day for a period of time. The trend chart also helps users understand the impact of certain events such as a Teradata version upgrade or a TASM ruleset change on the key metric. Towards the bottom of the screen, the Logged Queries tab provides key metrics for queries logged on the selected date. The Suspect Queries tab displays information for all logged queries that are designated as suspect. Suspect queries are those whose values surpass thresholds defined for the Query Log data collector in the Monitored Systems portlet.

On drill down to Users or Applications displays details about the Users or Applications that were running on the system, such as logged queries  or how many queries were classified as suspect queries etc. for a particular user or application. The screen shot below is from a drill down on Users. 

Further drill down to a particular user gives summary stats about the user such as number of logged queries, number of queries classified as suspect queries etc.. The queries tab lists all the queries submitted by the user as well as all the queries that were classified as suspect queries. The trend tab can be used to  plot multiple trend charts which helps analyze key performance indicators aggregated daily or weekly over a period of time. It also helps in analyzing  the impact of certain events such as the Teradata version change or TASM ruleset change on the key metrics for a user. The trend chart for applications also helps analyze impact of an application version change if Teradata recommended QueryBand format is followed, as Viewpoint picks up the application name and version from the QueryBand.

In the queries tab, further drill down to a query gives query level stats as to time spent in delay queue, KPI, workload details etc in the SQL and Query Band tab, one can see SQL and Query Band information.  

Application Queries

The Application Queries portlet helps application users understand their application performance. The Application Queries view displays summary information for each application and its different versions that submitted queries on a selected date. Drill down to a particular application gives summary stats about the application such as number of logged queries, number of queries classified as suspect queries etc.. The queries tab lists all the queries submitted by the application and  all the queries that were classified as suspect queries. The trend tab allows users to plot multiple trend charts which helps analyze key performance indicators, aggregated daily or weekly over a period of time for the application. Users can also see the impact of certain events such as Teradata version change or TASM ruleset change or application version change. 

In the queries tab, further drill down to a query gives query level stats as to time spent in delay queue, KPI, workload details etc, in the SQL and QueryBand tabs, one can see this information.

If the Teradata recommended QueryBand format is followed, Viewpoint automatically generates the application name using QueryBand information, administrator can assign Viewpoint users or roles to those applications in Query Group Setup portlet so that application users can see details about the applications in Application Queries portlet. If the Teradata recommended QueryBand format is not follwed, one can define applications in the Query Group Setup portlet and assign Viewpoint users or roles to them. 

Performance Data Collection and Reporting (PDCR) Scheduling

PDCR is a Teradata PS offering which collects historical data from various Teradata system tables (ResUsage, QueryLog, AmpUsage, LogonOff, TDWM) and stores within a PDCR database defined on a Teradata system. This database is then used to generate a series of customer performance analysis reports (Excel Toolkit and PS Viewpoint portlets).

PDCR involves:

  • Creation of PDCR infrastructure –  This can be done using PDCR dip script which is part of Teradata Database 14.00 and newer
  • Regular scheduling of maintenance job which moves data from Teradata system tables to the PDCR database. This can now be done using Viewpoint 15.10 on Teradata Database 15.00 and newer. Prior to this new offering, PS developed scripts were used for maintenance jobs.
  • Upgrade & Migration of PDCR database is still handled by Teradata PS
  • The PDCR excel tool kit reports and PDCR Viewpoint reporting portlets remain a Teradata PS offer.
  • The Query Log and Application Queries portlets provided in Viewpoint 15.10 use the PDCR data repository.

The PDCR scheduling portlet allows you to create, monitor and manage PDCR scheduling jobs. You can see when a particular job was last executed, whether a job was successful or failed, if failed what was the error, how many rows were accessed, tables that were loaded etc.. It also allows you to send alerts for failed jobs or when PDCR staging/reporting database reaches  space limit thresholds. 

Products Support - Teradata Database 15.10 Support

Following features in Viewpoint 15.10 requires Teradata Database 15.10 and above.

Secure Zone

Teradata Database 15.10 added the Secure Zones feature to support multi-tenancy environment or sandbox environment. This feature restricts user access to  set of database objects. Viewpoint 15.10 is built with Secure Zone awareness by assigning zones to a role in the Roles Manager portlet. Once a zone is assigned, Viewpoint users in that role when accessing the listed portlets below will only see details or queries accessing the objects assigned to a particular zone.

  • Queries Portlets (Query Monitor, MyQueries, etc.)
  • Query Log
  • Application Queries
  • Space Usage
  • Lock Viewer

In the below screenshot, the "0 of 2" for "WD" system means that out of 2 zones defined on the WD system, no zones are assigned to Administrator role. One can click on the "0 of 2" screen to assign zones to a role.

Partition Level Lock:

Teradata Database 15.10 introduced a new locking mechanism to improve partition level access. Viewpoint will display these locks in the Query Monitor and Lock Viewer portlets.

The QueryBand Option in Profiles

Teradata Database 15.10 added an option to set QueryBands in profile which will be the default queryband for a session. In Viewpoint, the user can view the profile queryband in the QueryBand tab in the Query Monitor portlet.  

Stored Procedure Monitoring

Viewpoint 15.10 can now differentiate between a SQL that is part of a stored procedure or not.  The SQL tab in the Query Monitor drill down will now display the stored procedure name.

Proxy User Information

Teradata Database 15.10 will allow users to log on as a proxy user and use access rights of that proxy user. Viewpoint 15.10 will show the proxy user details in the Query Monitor overview drill down tab and the Workload Monitor portlet. See the screenshot below.

Request Level Skew

Viewpoint 15.10 along with Teradata Database 15.10 can now report request level CPU and IO skew in addition to snapshot skew information. For this, the overview tab in the Query Monitor portlet was re-arranged.  

Products Support – Workload Management

Unless stated explicitly all new workload management features require Teradata Database 15.10 and newer. Viewpoint 15.10 supports the following workload management features:

  • Users now have an option to prioritize the delay queue based on workload priority. Users can now choose to release queries based on workload priority instead of only FIFO.
  • Users can now separately classify backup and restore job
  • Users can now classify on a MloadX utility
  • Users can now define an AMP Worker Task (AWT) throttle for Utility Name, Request Source, Query Band, DSA job type, or a combination of these criteria.
  • Users now have a new minimum response time option which will allow them to hold a query in a response state until the minimum workload response time threshold is met

In the Workload Monitor portlet when drilling into the delay request throttle view, there are additional tabs as shown in the screen shot below. This is supported for Teradata Database 13.10 and newer.

  •     By Workload - same as the previous view, displays all the sessions that are currently delayed
  •     By Throttle - Display all queries included in a throttle counter. A query that is included in a throttle counter might still be executing, it is only delayed if the limit is exceeded.
  •     By Throttle count - Displays the counters for each active throttle. For Teradata DB 15.10, this will now also display system default throttle. 

Products Support –  Aster 6.10 Support

The Viewpoint 15.10 release supports Aster Database 6.10. With this release of Viewpoint 15.10 users can cancel any process or queries running on Aster Database 6.10 and above. This is done by having Viewpoint submit an asynchronous abort to the database.

Alerts

  • Include/Exclude by Account string was added for session alerts to include/exclude account strings while defining events for session alerts.
  • User can now send alerts for a session stuck in responding state.

Online Restore and Server Migration

Migrating to a new Viewpoint server or restoring a Viewpoint server has been made easy with minimized downtime. This was accomplished by only taking Viewpoint services offline while configuration data is restored. They system is then made available as the historical data is restored in the background.

Progress of the restore or migration can be monitored in the Viewpoint portal notification area.

Below are three restore/migration options that are now supported:

  • A configuration only restore.
  • Configuration only restore or migration into a clean database.
  • A full restore or migration

Cluster Notification 

A list of e-mail addresses can now be configured to receive cluster related e-mail notifications

Please refer the compatibility matrix and associated Viewpoint Configuration Guide for details of the upgrade process and the User Guide for details of new features.

Hope you like these new changes in Tearadata Viewpoint 15.10. We always look forward to your thoughts and comments.

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

What's New in Viewpoint 15.10

$
0
0
Course Number: 
54208
Training Format: 
Recorded webcast

This presentation provides an overview of the Teradata Viewpoint 15.10 release and includes live demonstration of some of the new portlets added in this release.

Presenter: Shrity Verma, Product Manager - Teradata

Audience: 
Database Administrators, Application Developers, Business Users
Price: 
$195
Credit Hours: 
1
Channel: 

Viewpoint 15.11 Charting Update

$
0
0
Short teaser: 
Viewpoint has adopted an open source charting framework to replace the proprietary TjsChart.
Cover Image: 

Technology Overview

The technologies used in this framework are highly responsive to data manipulation on charts.

The new charting frameworks uses following third-party client side libraries:

  • crossfilter.js - Crossfilter is a Javascript library for exploring large multivariate datasets in the browser.
  • d3.js - D3.js is a JavaScript library for manipulating documents based on data.
  • dc.js - dc.js is a javascript charting library with native crossfilter support and allowing highly efficient exploration on large multi-dimensional dataset. It leverages d3 engine to render charts in css friendly scalable vector graphics (SVG) format.

These technologies are configured to work with the current Viewpoint Portal. Hammer.js is used to provide support for chart balloons on mobile platforms.

Features Supported

The following scales are supported on both the Axis:

  • X-Axis Linear and Time Scales
  • Y-Axis Linear and Percent Scales

Other basic features like coloring, grid-lines, rendering area, rendering data points, configuring min-max are supported.
The framework is flexible enough to provide native D3 chart object if required, to add special features on D3 charts.

Special features added by viewpoint include:

  • threshold-based coloring
  • area charts (stacked min-avg-max)
  • support for line segment to the last point before the chart start
  • support for partial width first bar
  • support for "off the chart" indicators
  • null values and line graphs with data islands (nulls on either side)
  • custom axis labelling (to support Viewpoint Profile adjust time)
  • detail information balloons
  • NOW line and label

Data for the views can be provided as a Backbone model or as raw data in chartConfig.
A chart by default takes the size of the container in which its rendered. The client for the chartView can also provide 'width' and 'height' options for the chart if it needs to be rendered with specific dimensions.


If the size of chart container changes (resize), the chart needs to be re-rendered to fit the new container size. Whenever new data is available from the server (refresh), the charts will update its crossfilter with new data and re-draw the chart.

Developing with Chart Views

In 15.11, most of the portlets with charts were converted to use our backbone views.  The new chart stack is not implemented in any old style portlets.

There are two ways in which the chart views can be constructed. It can be directly configured as childView or it can be extended to add other views/functionality into that view. If the chart is configured as a childView, then it is the parent view's responsibility to fetch the data and pass it to the chart as a 'chartData' option to the view. When the view is extended, the data is to be fetched by the extending view and can directly use it as its chartData variable.

There are 2 categores of charts, simple dc-based charts with 1 series and no thresholds can use the streamlined barChartView or lineChartView.

Charts with multiple series or with thresholds need to use the more involved compositeChartView.js, which uses an array of sub-charts.

Chart configuration options are documented in baseChartView.js.

 

 

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

System Performance Monitoring

$
0
0
Course Number: 
54351
Training Format: 
Recorded webcast

This session focuses on Monitoring for System Performance. 

We look at how to leverage Viewpoint and Performance Data Collection in concert in order to identify performance bottle necks and focus performance tuning efforts.

Presenter: Dan Fritz - Teradata Corporation

Price: 
$195
Credit Hours: 
1
Channel: 

Teradata Data Lab 15.11 Release

$
0
0
Short teaser: 
Provides an overview of new feature functionality introduced with the Data Lab 15.11 release
Cover Image: 

The Teradata Data Lab 15.11 release is now available with formal GCA release in early November 2015. This article will discuss the latest enhancements. Note that Data Lab 15.11 was a relatively "light" release due to the significant changes made in the Teradata Data Lab 15.10 release in both visualization as well as feature functionality. There is still some good stuff here however so read on.

Data Lab Concept:

To review, the key concept around Teradata Data Lab is to stop moving production data out of production to feed analytical islands, such as spread marts or data marts. Instead, move the analytical proofing data into a production intelligent sandbox environment where Data Lab provides production protection for the DBA while allowing self-service provisioning and governance capabilities desired by the analytical community. A much better approach in terms of data security, user efficiency, system resource usage, and proofing confidence to name just a few of the benefits.

Data Lab 15.11:

This latest release of Data Lab provides some nice updates but as mentioned was a light release to allow some settling due to the extensive changes in the Data Lab 15.10 release. This article will discuss four new features released with Data Lab 15.11, those being:

So let's take a look at each of these in more detail.

Expedite a Data Lab Expiration:

Teradata Data Lab has always had the concept of an “expiration date” for data labs which included the ability to request an extension to postpone the expiration. However some customer situations encountered where the expiration date actually wanted to be moved in instead of moved out. For instance, when a lab group owner inadvertently approves a longer extension than desired. When this happened in previous releases, there was no easy way to expedite or pull in that extended date. This new feature allows data lab owners to change the expiration date to an earlier date through a simple menu modification option. This new feature however does not allow one to extend the date. In short, the data lab extensions work the same as they did before. This new option is offered as part of the Edit Lab Details selection as shown below which is only visible if you have full permissions to the data lab. Note the expiration date for the Americas data lab is a year later than the Asia and Europe data labs and let's say therefore needs an adjustment.

Below is the updated "Edit Lab Details" screen including the new section stating the existing data lab expiration date and the ability to set a new expedited (earlier) expiration date. A request for a later date will result in an error stating that the "New expiration must predate current expiration".

Lab Group Access Display:

Teradata Data Lab offers two types of access (read-only or full permissions) at two different levels (lab group or data lab). The ability to easily view these access levels was added in the Data Lab 15.10 release through the "View Lab Group Details" and "View Lab Details" requests. Worth reminding everyone that these views are not defaults and need to be enabled within the configuration of each lab group through a simple checkbox. With Data Lab 15.11 release, we modified the "View Lab Details" to display two sections, one for access at the data lab level and another for displaying access from the lab group level. This now presents a full view of who has access and from what level has it been granted. Here is an example of the new "View Lab Details" access display:

Data Lab Access Reports:

The new Data Lab “Access Reports” (offered as a new tab in the Data Labs portlet) provide an easy way for permission enabled users to understand Teradata Database access rights within the Teradata System Data Lab infrastructure. So the ability to easily see user access across all aspects of a lab group or lab groups without the need to individually look at each data lab for understanding set access. The “Report type” includes three options: User, Role, and Lab group to report on user access, role access, or all access within a specified lab group or groups. One could use these new reports for example to get an access layout of an entire lab group or to understand where a particular user has access to across all lab groups. As an example, here is creation of a report to determine where Ann and Sam have access and associated permission:

And the resulting report. Note there is an export option if this information needs to be used outside of Viewpoint.

As mentioned, viewing Data Lab Access Reports is a permissioned operation within Viewpoint Administration - Roles Manager and specifically within the Data Lab settings. This is the same location for granting lab group modification privileges. 

Data Lab Migration:

This new process solution leveraging the new “migratedatalabssystem” command can be used in conjunction with Teradata DB System “floor sweeps / system migrations” where a new Teradata Database System is replacing an older Teradata Database System and where the customer also wants their Data Lab environment to migrate to the new system. There are two parts for success here. The first is that the Teradata DB system – Data Lab objects, users, roles, etc. must move over as part of the Teradata DB system NPARC. The second portion is a migration of the Viewpoint “Data Lab” infrastructure within the Viewpoint instance. This is the new process where we can now automatically migrate the “Data Lab” infrastructure with the floor sweep. Some points to understand about this new feature. The Viewpoint “Data Lab” migration must occur on the same Viewpoint instance so there is no export / import from one Viewpoint instance to another. Also this feature should not be perceived as a “quick start” way to implement a new Data Lab environment as it is a transfer of the infrastructure, not a copy. The process for a Data Lab migration is documented in the Teradata Viewpoint Software Installation, Configuration, and Upgrade Guide for Customers, Release 15.11.

Some compatibility aspects worth mentioning. Data Lab 15.11 requires Viewpoint 15.11 and vice versa. Viewpoint and Data Lab 15.11 are supported with the following versions of Teradata Database (15.10, 15.00, 14.10, 14.00, 13.10). Teradata Data Lab is not currently offered with Aster or Hadoop systems. 

Thanks for taking the time to peruse this article!

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

An Overview of the new Viewpoint 15.11 Dashboard

$
0
0
Additional contributors: 
Cover Image: 

Summary

The Viewpoint Dashboard (released with Viewpoint 15.11) is designed to give you an at-a-glance overview of monitored systems while you perform your everyday tasks. If something catches your eye you can quickly switch to the Dashboard for a system and begin a more in-depth investigation.

The Viewpoint Dashboard pulls together data from the System Health, Query Monitor, Alert Viewer, Metrics Analysis, and Workload Monitor portlets in order to support monitoring and management of Teradata, Aster, and Hadoop systems. To get started with the dashboard, be sure it is enabled in Roles Manager and then look for System Health status icons stacked vertically on the left side of the screen. Hover over a status icon to see the system name and health state. When you want to see more detail about a system, click its health icon.

Dashboard System Overview

When expanded, the Dashboard initially shows an overview for the selected system. For this at-a-glance system overview, there are 5 main content areas:

  1. Trend graphs for key metrics
  2. System Health metrics that have exceeded thresholds
  3. Workload details such as the current ruleset, state, and top active workloads
  4. Query details showing counts of queries in each state and the top 5 lists for queries including
    • Highest Request CPU
    • Highest CPU Skew Overhead
    • Longest Duration
    • Longest Delayed
  5. Alert details showing counts of alerts in each state

 

System Health Details

Clicking the System Health section of the system overview screen takes you to the System Health details page, which displays detailed information about each key performance indicator metric used to evaluate the overall health of a system.

To navigate back to the system overview, click the system name in the list on the left. To navigate to other data associated with the current system, click one of the boxes to the right of the list of system names. Each box contains a summary of the most important information from each section so that you can continue to see a system overview while investigating the details of individual sections.

 

Workload Details

To see more information about workload management workloads, click the name of an active workload on the Workloads section of the system overview screen. In addition to the ruleset, state, and active workload information from the system overview, new information is available such as counts for current queries, cumulative data for queries that have been processed, and details for all workloads in the active ruleset. Click a workload name to display trend graphs for various metrics associated with the workload.

Query Details

For queries, there are a couple of ways to see detailed information depending on what piques your interest. At the top of the Queries section on the system overview screen, click a box containing a count of queries in given state to see all queries that are in the selected state. You can also click a query in the Top 5 section to see details for that query. Once you are on the details page you can filter the list of queries just like in Query Monitor. Click any query to see details below. The down arrow next to the session number in the details area provides standard functions such as aborting and changing workloads.

Alert Details

The Alerts detail page allows you to view triggered alerts for the selected system. To access the alert details, click the box containing an alert count on the Alerts section of the system overview screen. Once you are on the details page, click an alert see more information such as general alert information (e.g. when the alert occurred and the alert criteria), what triggered the alert (e.g. details about the actual issue), and any additional messages.

Dashboard Rewind

In addition to viewing current data in the dashboard, you can use the Viewpoint Rewind feature to roll back and see data from the past just like you can for portlets outside of the dashboard. When using Rewind with the full dashboard displayed, all data for all systems is rewound, not just the current system. To help prevent confusion when the dashboard is minimized, the dashboard icons show the current status regardless of whether or not Rewind is enabled for the dashboard.

The Viewpoint 15.11 dashboard should make Teradata system monitoring easier than ever before. Enjoy. 

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

Introduction to Viewpoint 15.11 Mobile

$
0
0
Additional contributors: 
Cover Image: 

Summary

Introduced in Viewpoint 15.11, Viewpoint Mobile is a new way of monitoring and managing your Teradata systems using an interface optimized for smaller devices. Viewpoint Mobile is designed to pull together the most relevant data and features from the System Health,Query Monitor, Alert Viewer, Metrics Analysis, and SQL Scratchpad portlets in order to support system monitoring and management while on the go. Whether you have Teradata, Aster, or Hadoop systems, Viewpoint Mobile allows you to monitor the health of those systems and to perform common management tasks. For example  aborting a query or changing the workload for a query on a Teradata DB system.

Viewpoint Mobile is implemented as a web application so it does not require an app download; just open a mobile browser using the same URL you always use. The mobile interface does not simply mirror the standard desktop UI to small devices, rather, it has been tailored to give you the mobile experience you expect:

·      A wide range of screens are supported

·      Touch based control

·      The number and size of files that are sent to the browser have been reduced to increase network performance and to ensure Viewpoint does not eat-up your data plan

·      Important data is surfaced so you can see the information you need without a lot of digging

Login

To get started, launch Viewpoint Mobile by opening the standard Viewpoint URL on your mobile device. If you have been granted access to Viewpoint Mobile in Roles Manager you will have access to the mobile experience, otherwise, you will see the desktop interface. If you are using a larger format device such as a tablet you can switch to the desktop interface at any time.

Home

The mobile homepage contains a System Health overview, with information about the overall health of monitored systems and up to three metrics that have exceeded thresholds. To see additional details, tap a system.

System Overview

The System Overview page provides a high level snapshot of status and activity for the selected system, including:

  • Trend graphs for key metrics
  • System Health metrics that have exceeded thresholds
  • Number of active, blocked, and delayed queries
  • Number of critical and high alerts

You can drill down on system health, queries, or alerts for more information.

System Health Details

The System Health details view displays the same metrics information that you are accustomed to seeing in the System Health portlet. While a key performance indicator metric threshold is exceeded, a sparkline is shown to help with investigation. For metrics that do not currently exceed a threshold, tap a metric to view its sparkline.

Queries

Just like Query Monitor portlet, the Query view shows a list of queries running on your system. Use the filter in the upper-right to filter the view by query status to focus on active, blocked, delayed, or other queries. When you find something of interest, tap the query to drill down and get access to additional information and management functions.

 

Query Details

The Query Details view once again leverages the familiar Query Monitor interface to show query metrics, SQL, explain, query band, and more. To access each "tab" of data, swipe sideways. To access the functions you need to effectively manage the query, tap the Actions menu.

Alerts

The Alerts view leverages the power of Viewpoint alerts to keep you informed when an interesting event occurs. Just like Alert Viewer, this view lists recent triggered alerts and can be filtered to show alerts of different severity. To see details, tap an alert.

Alert Details

The Alert Details view provides the who, what, where, and when for the selected alert. If you review the alert and determine that it is no big deal, use the Actions menu to hide the alert and reduce clutter in the Alerts list.

If you need more information or need to take immediate action, use the main navigation menu in the upper-right to quickly jump to the data and features you need.

 

SQL Mobile

The SQL Mobile view provides all of the access you are accustomed to in the SQL Scratchpad portlet. You can type a new query, load a previously run query, load a saved query, and run queries to retrieve query results from a Teradata Database system. You access the editor using the main navigation menu.

Customization

We realize that different users are interested in different information and data from different time frames. To help you see the data you need, Viewpoint Mobile lets you customize different views using the Settings interface. Want to customize the columns for the Queries list? Want to change which systems are monitored? Want to limit the display of alerts to only those that occurred in the last 24 hours? Just open up Settings and specify what data you want to see in Viewpoint Mobile.

Conclusion

That should give you a pretty good idea of what you can expect from the new Viewpoint Mobile. We have done our best to expose the right data at the right time in this initial release of Viewpoint Mobile and look forward to hearing about people's experiences with it so we can make improvements over time. Thanks.

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

Teradata Viewpoint & Teradata Alerts User Guides

$
0
0

The Teradata Viewpoint User Guide provides information about how to use Teradata Viewpoint and associated portlets. This user guide is essentially the content found in the Teradata Viewpoint on-line help offered in PDF format.

You can also download the Teradata Alerts User Guide here. Note that Teradata alerts is now integrated with the Viewpoint 15.10 User Guide.

Download Teradata Viewpoint User Guide:

Download Teradata Alerts User Guide:

For community support, please visit the Viewpoint forum.

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

Upgrading a Viewpoint 14.00 Portlet to 14.01

$
0
0

A portlet developed for Viewpoint 14.0 will, for the most part, work correctly on Viewpoint 14.01. The most impactful change to consider will be to make your portlet support horizontal resizing, and to make any code changes to use the latest versions of jQuery and jQuery UI included with Viewpoint 14.01.

 

Modify ivy.xml to use 14.01 jars

If you are developing inside of the Teradata network you will need to modify the ivy.xml file for your portlet to use latest jar files. If you are not then go to the next step.
Edit ivy.xml and replace tdcommons-* with vp-commons-* for Viewpoint jars. You will also need to rename organization from teradata to com.teradata.viewpoint for these jars. Update your ivy.xml or project.properties, whichever contains the actual revisions with the latest revisions. The final result should look as below.

NOTE: The structure of the ivy.xml file has changed in 14.01, but the existing structure will continue to work.

ivy.xml
<dependency org="com.teradata.viewpoint" name="vp-commons-portlets" rev="14.01.00.00-SNAPSHOT" conf="runtime->runtime" changing="true" />
<dependency org="com.teradata.viewpoint" name="vp-commons-model" rev="14.01.00.00-SNAPSHOT" conf="runtime->runtime" changing="true" />
<dependency org="com.teradata.viewpoint" name="vp-commons-security" rev="14.01.00.00-SNAPSHOT" conf="runtime->runtime" changing="true" />
<dependency org="com.teradata.viewpoint" name="vp-commons-testutil" rev="14.01.00.00-SNAPSHOT" conf="build->build" changing="true" />
<dependency org="com.teradata.viewpoint" name="vp-commons-taglib" rev="14.01.00.00-SNAPSHOT" conf="runtime->runtime" changing="true" />
<dependency org="teradata" name="anterage" rev="latest.integration" conf="runtime->runtime" changing="true" />
<dependency org="teradata" name="TeraJDBC" rev="latest.integration" conf="runtime->default" />
project.properties
 
#
# Dependency Versions
#
cam.version=14.01.00.00-SNAPSHOT
anterage.version=latest.integration
tvilogging.version=1.3
datatools.version=latest.integration
tomcat.version=7.0.32
spring.version=3.0.5.RELEASE

#
# Java Version options used for compilation
#
javac.source=1.6
javac.target=1.6

#
# JDBC Dependency Versions
# module is TeraJDBC-PreGCA to get JDBC candidate builds
# module is TeraJDBC to get only JDBC GCA builds
#
terajdbc.module=TeraJDBC-PreGCA
terajdbc.version=latest.integration

postgresjdbc.module=postgresql-jdbc3
postgresjdbc.version=9.1-901

Manually move new jar files to your portlet

If you are developing external to the Teradata network you will need to manually update your portlet with new jar files. First delete all of the old jar files from your WEB-INF folder. There are located here:
C:\tdpdk-14.00.00.00\src\YourPortletName\web\WEB-INF\lib

Now grab the new jar files from one of the demo portlets that were generated with the 14.01.00.00 PDK, and put them in the folders that you just removed the old ones from. If you were to grab them from the DynamicQuery portlet, you would find them here:
C:\tdpdk-14.01.00.00\viewpoint-portal\webapps\DynamicQuery\web\WEB-INF\lib

Support Horizontal Resizing

This is covered in the PDK Cookbook.

Upgrade jQuery usage 

If your portlet uses jQuery or jQuery UI, you will want to check your code to remove deprecated calls. See below for a list of common gotchas and best practices to follow.

What has changed?

  • jQuery: Upgrading from 1.2.6 & 1.4.2  to 1.7.2
  • jQuery UI: Upgrading from 1.5.2 & 1.8 to 1.8.19
  • jQuery Aliases: The following aliases are deprecated and will be removed in 14.10 - JQ, jQuery12, and jQuery14. In 14.01 these aliases will point to jQuery 1.7.2. All other versions of jQuery and jQuery UI will be removed in 14.01.

What do I have to do?

  • Remove deprecated attribute selectors
    • Search code for '[@' (be careful not to accidently replace this in regular expressions within your code base)
    • Replace ?'[@' with'['
  • Ensure that $('formElementCollection').focus() is only setting the focus on visible and enabled form fields else it will throw an error in some browsers
    • If you are uncertain of a form field's state during run time you can apply filters to your selectors that are setting focus: $('formElementCollection:visible:enabled').focus()
  • $(selector).attr('foo') will return undefined if an attribute has not been set, so if you attempt to access a property such as $(selector).attr('foo').length then it will throw an error in some browsers
    • Just check for truthiness instead of trying to access a property; empty strings will return false, so a truthiness check should cover all cases
    • If you are mixing vanilla JavaScript with jQuery then trying to access attributes via $.attr()
      • BAD: var foo = document.getElementById('bar'); foo.myCustomAttr = 'baz'; // this is a property not an attribute
      • GOOD: var foo = document.getElementById('bar'); foo.setAttribute('myCustomAttr', 'baz');
      • Use jQuery.prop for getting and setting properties, e.g., checked, disabled, etc.
      • Use jQuery.attr for getting and setting attributes
      • Do NOT use jQuery.removeProp on native element properties; you should never need to use this unless your setting expandos on DOM elements which is bad practice in the first place

Upgrade Widgets

If your portlet uses the TjsDatagrid or the BigNumbers widget, refer to Displaying Tabular Data or the SkewedSessions portlet shipped with the PDK for examples of resizing widgets.

Run your new 14.01-compatible portlet

Your portlet is now ready to be deployed within the Viewpoint 14.0.1 environment.

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

Displaying Tabular Data using the DataGrid and BigNumbers Widget

$
0
0

The following tutorial is a guide on how to implement the Viewpoint DataGrid and BigNumbers Widget.  In this example we will show how these widgets were incorporated into the SkewedSessions Portlet.  The actual source code can be found in the SkewedSessions Portlet supplied in PDK version 14.01.

 

What is the DataGrid Widget

The DataGrid Widget was created to address the issue of displaying large amounts of data in tabular format within portlets.  The widget currently includes an extensive list of built in features such as:

  • Fixed top header as data scrolls
  • Sortable columns
  • Filterable columns
  • User-configurable column widths
  • User-configurable column ordering
  • User-configurable column hiding
  • Columns can be fixed on the left
  • Built-in support for row menus
  • Built-in support for a checkbox column
  • Supports row drilldown
  • Supports large datasets with paging controls
  • Built-in support for column threshold value highlighting
  • Custom column sorting functions can be specified
  • Custom column display functions can be specified
  • Extensible widget menu options

What is the BigNumbers Widget

The BigNumbers Widget is used in conjunction with the DataGrid widget, and acts as a filter on the tabular data displayed in the DataGrid.

What we will be doing in this tutorial

In this tutorial we will describe how the SkewedSessions portlet displays skewed sessions data using the DataGrid and BigNumbers widgets.  We will start from the tags in jsp pages, then to the view controller and finally all the necessary back end support components. 

Note; This tutorial assumes that the portlet has been modified to support horizontal resizing. See instructions at Upgrading a Viewpoint 14.0 Portlet to 14.01

Widget tags in the JSP page

The first thing to note is the DIV tags in the summary-content.jsp page where we want the widgets to appear.  It is important that the DIV tag's IDs  match what is supplied in the widget tags.

SkewedSessions\web\WEB-INF\portlet-jsp\summary-content.jsp:

...
<div id="bigNumbersdataGridDiv${context}"></div>
<div id="dataGridDiv${context}"></div>
...

Next, note the DataGrid Widget JSP tag in the summary-content.jsp page in the SkewedSessions Portlet.  Few important attributes are listed below. See viewpoint-core.tld for a full listing.

  • context (required): the unique context id of the portlet.
  • url (required): the target url for the ajax request to fetch data.
  • widgetdomId (required): the id of the containing div for the DataGrid widget.
  • className (optional): CSS class to be applied to the element containing the widget
  • controllerName (optional): Javascript controller class to be used in place of the default
  • requestFunction (optional): The name of the function that will request data from the server
  • responseFunction (optional): The name of the function that will handle responses from the server
  • width / minWidth (optional): the width of the DataGrid in pixels
  • height / minHeight / maxHeight (optional): the height of the DataGrid in pixels
  • fixedColumns (optional): The number of fixed columns in the widget
  • clientSort (optional): Indicates whether or not to perform sorting on the client side. Defaults to true
  • bigNumbersWidth / bigNumbersWidthMin / bigNumbersWidthMax (optional): The width of the BigNumbers widget in pixels
  • bigNumbersCount (optional): The count of the BigNumbers bubbles
  • pageSize (optional): the size of each page displayed by the DataGrid.

SkewedSessions\web\WEB-INF\portlet-jsp\summary-content.jsp:

<vp:dataGrid context="${context}"
    url="/SkewedSessionsPortlet/dataserver/getSkewedSessionsReportData"
    widgetDomId="dataGridDiv${context}"
    bigNumbersWidthMin="86"
    bigNumbersWidthMax="100"
    requestFunction="requestFunction${context}"
    pageSize="250"
    clientSort="false" />

The View Controller

Next, we look at the controller which will pass the necessary data from the back end service layer to the DataGrid Widget we added in summary-content.jsp: SkewedSessionsViewController.

This controller has a method called getSkewedSessionsReportData(), which is called by DataGrid widget tag in the summary page.  This method will construct the TableState object used by the DataGrid to generate the view, and also retrieve the data we want displayed from the back end service layer. The TableState object is a representation of the state of the DataGrid Widget.  It incorporates both the configuration settings of the widget, and any data that has been retrieved so far. 

The Controller is responsible for maintaining the TableState object, both configuration (what page it is on, what columns are sorted, etc.), and   data, and returning this to the View. The DataGrid and BigNumbers widget will then render this data.

The DataGrid widget can send three type of requests to the Controller:

  • Data Request
  • BigNumbers Update Request
  • Preference Update Request

 

SkewedSessions\src\java\com\teradata\portlets\skewedsessions\controllers\SkewedSessionsViewController.java

...
public void getSkewedSessionsReportData(ControllerContext context) throws JSONException
{
	SkewedSessionsPreferences prefs = (SkewedSessionsPreferences) ctx.loadPreferences(
                SKEWED_SESSIONS, new SkewedSessionsPreferences());
        
        String stateParam = ctx.getParameter(TableState.PARAM_NAME);
        TableState state = null;
        if (stateParam != null)
        {
            state = TableState.newInstanceFromJson(stateParam);
        }
        
        if (isBigNumbersUpdate(ctx))
        {
            updateBigNumbersPreferences(ctx, prefs);
        }
 
        if (isPreferenceUpdate(state))
        {
            handleTableStatePreferenceUpdate(ctx, state);
        }
 
        if (isDataRequest(ctx, state))
        {
            executeReport(ctx, state);
        }
}
 

Data Request

A data request is a request to retrieve new or additional data.  This typically happens when the user navigates to the page, or the portlet auto refreshes, or the user applies a new filter or sort.  

When a data request is received, the Controller merges the current TableState with the previous saved state to preserve the settings.  It then fetches the data and places it into the merged TableState object to be passed back to the View. 

SkewedSessions\src\java\com\teradata\portlets\skewedsessions\controllers\SkewedSessionsViewController.java

/**
 * Execute the updated report and update state 
 * @param context the portlet context
 * @param newState the table state
 */
private TableState executeReport (ControllerContext context, TableState newState)
{
        // merge passed state into prefs' state
        SkewedSessionsPreferences prefs = (SkewedSessionsPreferences) context.loadPreferences(
            SKEWED_SESSIONS_PORTLET, new SkewedSessionsPreferences());
        TableState mergedState = prefs.getTableState();
        if (newState != null)
        {
            mergedState.mergeDataRequest(newState);
        }
     ...
        // create BigNumbers to populate with data
        BigNumbers<SkewedSessionsFilter> bigNumbers = new BigNumbers<SkewedSessionsFilter>();
        // execute report
        QueryResults<Session> dataGridResults = skewedSessionsManager
                .getCurrentSkewedSessions(prefs, bigNumbers, mergedState, context.getLocale());
        mergedState.setResults(dataGridResults);
        mergedState.setStatus(STATUS_OK);
    ...
        // serialize to JSON, add to view
        JSONBuilder builder = new JSONBuilder();
        tableStateJSONBuilder.toJSON(builder, mergedState, context.getLocale());
        builder.addArray(BIG_NUMBERS_RESPONSE, bigNumbers.getFilters().toArray());
        context.addViewObject(TABLE_STATE, builder.toString());
}

BigNumbers Update Request

A BigNumbers update request is a request to retrieve filtered data.  This happens when the user clicks on a BigNumbers filter.  The widget sends an HTTP request to the server with the "bigNumbersKey" parameter populated with the selected filter.

SkewedSessions\src\java\com\teradata\portlets\skewedsessions\controllers\SkewedSessionsViewController.java

    private static boolean isBigNumbersUpdate(ControllerContext ctx)
    {
        return !StringUtil.hasNullEmptyOrBlank(ctx.getParameter(BIG_NUMBERS_KEY));
    }    
 ....
    /**
     * Update BigNumbers filters in preferences
     * 
     * @param ctx the portlet context
     * @param preferences the portlet preferences
     */
    private void updateBigNumbersPreferences(ControllerContext ctx,
            SkewedSessionsPreferences preferences)
    {
        String bigNumbersKeyString = ctx.getParameter(BIG_NUMBERS_KEY);
        SkewedSessionsFilter filter = SkewedSessionsFilter.valueOf(bigNumbersKeyString);
        
        // update preference if new big numbers filter is different from existing filter
        if (isNotEmpty(bigNumbersKeyString) && !filter.equals(preferences.getFilter()))
        {
            preferences.setFilter(filter);
            ctx.savePreferences(SKEWED_SESSIONS_PORTLET, preferences);
        }
    }

Preference Update Request

A preference update request is one that persists the current configuration settings of the widget.  An example of such a request would be: resizing the column width, reordering columns in a report, etc..   The widget will send an HTTP request to the server with the "preferenceUpdate" flag set to true when this type of request is triggered.

SkewedSessions\src\java\com\teradata\portlets\skewedsessions\controllers\SkewedSessionsViewController.java

/**
 * Returns true if the tableState request is for preference update
 *
 * @param state the table state
 * @return true if preference update, false otherwise
 */
private static boolean isPreferenceUpdate(TableState state)
{
    return state != null && state.isPreferenceUpdate();
}
...
   /**
     * Merge TableState updates into TableState in preferences
     *
     * @param ctx the portlet context
     * @param newState the new TableState
     */
    private void handleTableStatePreferenceUpdate(ControllerContext ctx, TableState newState)
    {
        SkewedSessionsPreferences prefs = (SkewedSessionsPreferences) ctx.loadPreferences(
            SKEWED_SESSIONS_PORTLET, new SkewedSessionsPreferences());
        TableState savedState;
        savedState = prefs.getTableState();

        savedState.mergePreferenceRequest(newState);
        ctx.savePreferences(SKEWED_SESSIONS_PORTLET, prefs);
        ctx.setViewName(VIEW_EMPTY);
    }

Wiring up the Controller

Add the Controller to the portlet applicationContext.

SkewedSessions\web\WEB-INF\applicationContext.xml

...
<bean id="skewedSessionsViewController" class="com.teradata.portlets.skewedsessions.controllers.SkewedSessionsViewController">
    <description>Controller for summary and data requests</description>
    <property name="skewedSessionsManager" ref="skewedSessionsManager"/>
    <property name="messageSource" ref="messageSource" />
    <property name="tableStateJSONBuilder" ref="tableStateJSONBuilder" />
</bean>

<bean id="tableStateJSONBuilder" class="com.teradata.portlets.json.datatable.TableStateJSONBuilder">
    <constructor-arg index="0" ref="skewedSessionsColumnDefinitionClass" />
    <constructor-arg index="1" ref="messageSource" />
</bean>

<bean id="skewedSessionsColumnDefinitionClass" class="java.lang.Class" factory-method="forName">
    <constructor-arg index="0" value="com.teradata.portlets.skewedsessions.enums.SkewedSessionsColumn" />
</bean>
...

We also need to map the request url to the SkewedSessionsViewController.

SkewedSessions\web\WEB-INF\dataserver-servlet.xml

<bean id="handlerMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="mappings">
        <props>
            <prop key="/summary">skewedSessionsViewController</prop>
            <prop key="/getSkewedSessionsReportData">skewedSessionsViewController</prop>
            ...</props>
    </property>
</bean>

View that displays the JSON data need by the widget

The TableState object we created that contains the DataGrid settings and results need to be transformed into JSON so the widget can consume it.  We do this by calling the TableStateJSONBuilder, and then pass the generated JSON data to a simple jsp page for output and widget consumption.

SkewedSessions\web\WEB-INF\portlet-jsp\refreshSkewedSessions.jsp

<%@ page contentType="text/html" language="java"%>
...
${tableState} 

Back End Components

In order to support the DataGrid widget, there are several back end components that need to be created.

Implementing the TableColumnDefinition Interface

The TableColumnDefinition interface defines the methods that provide the necessary metadata for each of the columns in the DataGrid.  We will need to implement this interface and specify the column names and column types used in our DataGrid example.  Note, the columnName in the TableColumnDefinition needs to match the member name in the Model class (defined in the next section).

Here is a list of the standard column data types currently supported by the DataGrid widget:

TypeJava Class
String java.lang.String
Long java.lang.Long
Integer java.lang.Integer
Float java.lang.Float
Number java.lang.Integer
Timestamp java.sql.Timestamp
Duration java.lang.Integer
Checkbox java.lang.Boolean
Icon java.lang.String
Custom any

Our example DataGrid has 5 columns:

  • Session ID - type Integer
  • Username - type String
  • CPU - type Float
  • CPU Skew - type Float
  • Hot AMP - type Integer.

There are other column settings that can be set, such as turning on/off column filtering, hiding columns from the menu, and adding tool tips, etc..

SkewedSessions\src\java\com\teradata\portlets\skewedsessions\model\SkewedSessionsTableWidget.java

public enum SkewedSessionsColumn implements TableColumnDefinition
{
    SESSION_NO("sessionNo", TableColumnState.Type.NUMBER, true, false, null, "SESSION ID", "SESSION ID"),
    USER_NAME("userName", TableColumnState.Type.STRING, true, false, null, "USER NAME", "USER NAME"),
    REQUEST_AMP_CPU("requestAmpCPU", TableColumnState.Type.FLOAT, true, false, null, "CPU", "CPU"),
    CPU_SKEW("cpuSkew", TableColumnState.Type.FLOAT, true, false, null, "CPU SKEW", "CPU SKEW"),
    HOT_AMP("hotAmp1CPUId", TableColumnState.Type.FLOAT, true, false, null, "HOT AMP", "HOT AMP");
    ....

    private SkewedSessionsColumn(String columnName, TableColumnState.Type type, boolean filterable,
            boolean hiddenFromMenu, Integer defaultWidth, String header,
            String menuToolTip)
    {
        this.columnName = columnName;
        this.type = type;
        this.filterable = filterable;
        this.hiddenFromMenu = hiddenFromMenu;
        this.defaultWidth = defaultWidth;
        this.header = header;
        this.menuToolTip = menuToolTip;
    }
...

    public String getHeader(MessageSource messageSource, Locale locale)
    {
        return messageSource.getMessage(getName(), null, locale);
    }
}

Localization of header names is done by using the portlet resource bundle

SkewedSessions\src\resources\messages.properties

#data grid column headers
SESSION_NO=Session ID
USER_NAME=User Name
REQUEST_AMP_CPU=Request AMP CPU
CPU_SKEW=CPU Skew
HOT_AMP=Hot AMP

Adding preference items to support the DataGrid preferences

In order for the DataGrid to retain its settings after a user has logged out, the settings need to be saved in the portlet's preferences.  To do this, we will need to add the TableState object to the portlet's existing PreferencesModel with a PreferenceReference annotation.  You can add any number of objects, including different objects for normal view versus maximized view of a portlet if desired.

SkewedSessions\src\java\com\teradata\portlets\skewedsessions\model\SkewedSessionsPreferences.java

public class SkewedSessionsPreferences extends PreferencesModel
{
    // the DataGrid configuration
    @PreferenceReference
    private TableState tableState;

    // the BigNumbers filter
    @Preference
    private SkewedSessionsFilter filter;
   
    // constructor
    public SkewedSessionsPreferences()
    {
        // set default values
        ...
        tableState = initDefaultColumns(DEFAULT_SKEWED_SESSION_COLUMNS);
        filter = DEFAULT_FILTER;
    }

    // initialize TableState from preferences
    private TableState initDefaultColumns(SkewedSessionsColumn[] defaultColumns)
    {
        List defaultColumnsList = Arrays.asList(defaultColumns);

        TableState tableState = new TableState();
        for (SkewedSessionsColumn column : SkewedSessionsColumn.values())
        {
            TableColumnState columnState = new TableColumnState();
            columnState.setName(column.name());
            columnState.setColumnName(column.getColumnName());
            columnState.setHidden(!defaultColumnsList.contains(column));
            if (column == DEFAULT_SKEWED_SESSION_SORT_COLUMN)
            {
                columnState.setSortOrder(1);
                columnState.setSortAscending(true);
            }
            tableState.addColumn(columnState);
        }

        return tableState;
    }
   
...

Retrieving the data to be displayed in our DataGrid

The SkewedSessionsPortlet gets a list of skewed sessions for a selected system. The details of the query are not relevant to this discussion, but are available in the SkewedSessionsManagerImpl for reference. The DataGrid widget expects its results to be of type QueryResults. The Controller gets QueryResults from the Manager, and passes it to the TableState object, which is then serialized for consumption by the widget. this way, we are able to maintain separation between the Model, View and Controller in this application.

SkewedSessions\src\java\com\teradata\portlets\skewedsessions\service\SkewedSessionsManager.java

...
    /**
     * Gets a list of active skewed sessions running on the specified system. Each list item is a
     * session model.
     *
     * @param preferences  The users portlet preferences for this portlet instance.
     * @param bigNumbers  The session counts for big number widget (to be set)
     * @param tableState  The current TableState
     * @param locale  The users current locale
     * @return
     */
    public QueryResults<Session> getCurrentSkewedSessions(SkewedSessionsPreferences preferences,
            BigNumbers<SkewedSessionsFilter> bigNumbers, TableState tableState, Locale locale);
...

 

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0

How to Support "Resizing" for Viewpoint Portlets

$
0
0

Teradata Viewpoint 14.01 introduces a wider, more flexible layout, which better utilizes space on wide screen monitors, and gives the user more flexibility in controlling how much information is being displayed.

 

Does My Portlet Have to Support Resizing?

Portlets that do not support horizontal resizing will still function at the standard fixed-width, which is also the minimum supported width. However, most portlets will benefit from being able to display more information in the available screen real estate.

What Do I Need to Do to Support Resizing

Making your portlet horizontally resizable is fairly straightforward, and can be done in a few steps. Of course, you will want to update your portlet to make sure its layout can adapt to the resizable portlet container.

Edit your portlet.xml.

Add the following init-param. This tells the portal-framework that this portlet is horizontally resizable.

portlet.xml
<portlet>
  	<portlet-name>DynamicQuery</portlet-name>
  	<display-name>DynamicQuery</display-name>
        <init-param>
            <name>resizeHorizontal<name>
            <value>true</value>
        </init-param>
    ...
  </portlet>

Edit your include.jsp file

Edit your include.jsp to remove this line:

<script type="text/javascript" src="/CommonsWeb/js/jquery.js"></script>

And add:

<script type="text/javascript" src="/CommonsWeb/js/TDResizablePortletController.js"></script>

include.jsp
<vp:managedResources context="${context}"> 
...
<script type="text/javascript" src="/CommonsWeb/js/TDResizablePortletController"></script> 
</vp:managedResources >

Edit your registerPortlet tag

Edit your <vp:registerPortlet> tag to set supportsResizeHorizontal to true.

<vp:registerPortlet context="${context}"> 
     context='${context}'
     elementId="${context}_content"
     refreshUrl='/SkewedSessionsPortlet/dataserver/getSkewedSessionsReportData'
     refreshTarget='#tempDiv${context}'
     refreshInterval='30000'
     supportsResizeHorizontal='true' />

This is it! Your portlet container is now horizontally resizable.

Register Resize Callbacks

Your portlet will want to register functions which get called whenever a resize event occurs.

// triggered when the portal columns resize
TDPortalManager.onPortalResize(context, function () {}); 

// triggered when a portlet is (un)collapsed
TDPortalManager.onPortletCollapseToggle(context, function (collapsed) {}); 

// convenience method for clearing a portlet's resize callbacks
TDPortalManager.clearResizeAndCollapseCallbacks(context);  

For more concrete examples, refer to the sample portlets included in the PDK.

 

 

Ignore ancestor settings: 
0
Channel: 
Apply supersede status to children: 
0
Viewing all 81 articles
Browse latest View live