0 - 21 of 21 tags for teradata sample application

One of the biggest benefits of Query Banding is the ability to pass parameters into an SQL script.

Establishing an associative security table lookup between a userid and allowable company codes may allow easy access to the base data tables.  

In this Mini Section we are going to extend upon the Simple Quotation Engine from FNP#6 in order to do Quotation Management. This will involve persisting information from the “Get Quote” method including Customer and Property Details as well as the resulting Quotation information. In this first part we will discuss the business process and establish the new database tables we will need. In the second part we will create the necessary Data Access Objects using iBatis and wire the Quotation Manager into the Web service of FNP#8 and FNP#9, and in the third part we will complete the Quotation Management process by providing for the ability to buy a TZA Insurance Policy using the Web service.

After some time off (to do my real job) I'm going to do some more articles in the Friday Night project series [http://developer.teradata.com/applications/articles/the-friday-night-project].

I'm probably going to concentrate on iBatis to start with (what is it, how can it help me bridge the gap from Object to Relational, etc).

The Teradata Sample Application (upon which FNP is based) has examples of Web and Viewpoint Portlet Presentation veneers incorporating elements such as Hibernate O/R Mapping, ACEGI security and of course how to make your application work well on Teradata.

Back in FNP #11 Macros and Stored Procedures the Spring Framework concept of referencing a Parent bean was introduced as so:

In the first two parts of this Mini Section we have been looking at the concept of Embedding analytical processing directly within the Teradata Database. Part one used a SQL Stored Procedure to act as an Isolation layer between the Enterprise Application and the Teradata Database. Part two replicated this isolation concept using the Java External Stored Procedure (JXSP) approach. Part three combined the JXSP with the previously prepared, Spring Framework based, Business Processes. This final Part illustrates how to little code is now required in the Presentation Veneer (Web service process) due to the embedding of the Business Logic within the Teradata Database.

In the first two parts of this Mini Section we have been looking at the concept of Embedding analytical processing directly within the Teradata Database. In the first part we used a SQL Stored Procedure to act as an Isolation layer between the Enterprise Application and the Teradata Database. In the second part we progressed along the same line of providing an Isolation layer but this time we employed the Java External Stored Procedure (JXSP) approach. In this third part we combine the JXSP, as an Isolation layer in order to cross the great divide between the enterprise and the database, with the TZA-InsuranceProcess business processes developed previously.

Last time we introduced the SQL Stored Procedure as a means to provide for Embedded Analytics.

However, as of Teradata 12.0 it is possible to use the Java Language as the basis for External Stored Procedures (known as JXSP’s), so this week we will develop a Java based version of the ApplyRiskFactorsToQuote Stored Procedure.


Last time we introduced the Macro and the Stored Procedure as a means to provide for Isolation between the SQL call and the underlying database structure.

This week we are going to keep on the core Teradata trail by looking into Stored Procedures as means to provide for Embedded Processing.

Last time we did a full on What, Why and How description of some pretty Teradata specific information around Query Banding and showed how we could weave this into the Web Application and Data Access Layers so as to minimize the impact of this on the Business Service layer and it’s developers.

This week we are going to keep on the core Teradata trail by looking into Macros and Stored Procedures as means to provide for Isolation and Embedded Processing.

Last week we concluded by challenging you to consider how a Connection Pool contributes to the performance of Web and Web service applications. Further we suggested that this week we would expand on this thought by exploring what you can do, during the development of an Active Integration application, to achieve improved performance through collaborating with the Database on Workload Management.

Until now nothing that we have discussed has been dramatically different from any other Spring Framework / DAO / Web services / JEE / POJO tutorial, however, there is method to this madness in that it was necessary to introduce the Teradata Masters out there to some new Java concepts while leading the Java Masters into the Teradata fold. While this has taken a reasonable number of weeks to accomplish it should now be safe for the entire readership to enter the world of Teradata Workload Management and Query Banding together.

Last week we used the Eclipse WTP Web service Wizard to create the TZA Property Insurance Web service. We automatically created a series of plumbing code (within the com.teradata.tza.insurance.service and com.teradata.schemas.tza.insurance.service packages) plus a single Implementation (PropertyInsuranceSoapBindingImpl.java) class that the author is expected to customize. This class provides an SOA Presentation Veneer (User Interface) that can act as an entry point into the TZA-InsuranceService Business Process.

This week we will demonstrate how to "Wire" up the different parts of the project in order to connect the Web service Presentation Veneer into the Business Process, Business Objects and Repository layer and therefore on through to the database and the data tables.

So as we discussed previously TZA-Insurance operates as an Insurance Underwriter, allowing other Insurance Brokers to offer insurance services (insurance quotes and policies) to the final customer. In order to expose the business processes of TZA-Insurance we provide a Web service definition to its various Clients (Insurance Brokers, Web sites, etc) that allows them to create a Web service client interface within their application environment (Java or .Net). This Client interface then operates against the TZA Property Insurance Web service in order to initially get an insurance Quotation based upon the characteristics of the Property to be insured and then if acceptable to the Customer buy an Insurance Policy based around that Quotation.

In this session of the Friday Night Project we are finally going to create a Presentation Veneer that will use the Simple Quotation Engine business process we created last week.

However, don’t go getting all excited about MVC Web Pages, Portlets or Web services as we are going back to basics for this one with a plain old Command Line or Console Application interface. Think of it like “Basic Training” Toto, where we establish a usage pattern that we can apply across all further Presentation Veneers.

TZA-InsuranceProcess is a set of APIs which provide a Suite of Business Processes that represent TZA-Insurance, ranging from a simple Quotation Engine for the demonstration of the architectural concepts, through Complex Insurance and Quotation Management for Web and Web service applications to Insurance Summaries that can be represented in a Web Portal.

These APIs are written in Java and provide a series of Business Processes that behave independently from each other or which can be orchestrated to provide a larger Business Service or Process. These APIs are embedded into a single jar file [known as TZA-InsuranceProcess.jar] which relies upon other Teradata implicit objects [as jar files] which are included in its classpath, such as tdcommons-context.jar and tdcommons-access.jar.

Finally it’s time to start some real development within the Friday Night Project. This week we are going to create the TZA-Database project within which we will ultimately collect all of the project information (SQL, Data and build files) necessary to create and maintain a consistent version of the TZA-Database. We will also establish the base infrastructure for an ANT based build that can clear any existing database elements prior to creating the ZipCodeRiskFactors table and loading the base Risk Factors data.

Having previously introduced the “What”, “Why” and “How” of Active Integration and Solid Architecture, this week we start to build up the development environment (Eclipse with the Teradata Plug-In), Teradata Database Schema (TZA_DB) and User (TZA_USER) required to support TZA-Insurance.

If you are reading this then you presumably want to investigate and use the Teradata Database. As Teradata Developer Exchange is intended to address a wide range of users (Sales, Marketing, Engineering, Education) it is understandable that you may not have access to a “Full Power” Teradata (yet). However, fear not as Teradata Express Edition 12.0 allows you to have a, size restricted (4GB), Teradata 12.0 instance on your Windows PC or Laptop for evaluation and development purposes.

After a couple of Weeks of Introduction to the “What” and “Why” of Active Integration plus a start at the “How” around creating a Solid Architecture, this episode of the Friday Night Project introduces the Teradata Sample Application (TZA-Insurance).

Last Friday we defined the “What” and “Why” of our new Active Integration world.

So why don’t we start getting straight into the “How” and pick out some User Interface for each of our application classes?

Not so fast, let’s get some Solid Architecture principles in place before we start chasing up that pretty road Toto.

Welcome to the first article in The Friday Night Project series, where we'll starting with a background on the nature and role of the Enterprise Data Warehouse.

The aim of this, occasionally updated, set of articles is to assist a wide range of users to gain practical experience with developing “Active” Web, Web service and Portlet applications that are targeted at and make best use of Teradata.

The audience for this set of articles is expected to be very wide and will range from Teradata associates within the R&D and Professional Services organization through Teradata Customer and Partner developers (all of whom wish to learn and employ the advocated approaches to Teradata Application Development) to the potential “Next Generation” of Teradata oriented Developers that are currently in their final years of College/University and thinking about how to implement their Degree or Masters projects.