Mikec's picture
Company:
Country:
Personal Website:
Day Job:
blog icon Recent Articles

"udaSQL" provides a DevOps focused SQL Execution Engine that allows the developer to focus on their SQL and Procedural algorithms while ensuring that the needs of the Operations team are addressed by embedding operational and query logging directly into the engine.

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.

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.

TD12+

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.

blog icon Recent Reference

Mikec hasn't created any reference articles.