GeneXus 18 Proficiency course ENG

In this video we will try to provide a more perspective look and not so detailed, discovering when it is convenient to use the formulas according to their type and when we can use an alternative solution, in which cases we have restrictions and how we can lift them, what cost does adding redundancy imply and other observations that help us integrate the concepts on this topic.

What happens when we add new attributes to a transaction and records have already been entered in its table.

It is presented how to make inferred attributes and formulas, which by definition are not attributes stored in a database, can be defined as redundant and become one more field in a table. It is also analyzed how the value of these redundancies is maintained by changing the values of the attributes that are inferred and also in the event that the formula must be recalculated.

A summary of the different use cases of subtypes seen in previous courses is presented. In addition, a new case study is introduced that analyzes why we should avoid the referential relationship.

Through a case study, we analyze a design model scenario in which if the transaction form is executed, GeneXus cannot control the referential integrity of the data automatically.

Possibility of creating several transactions with the same identifier: what they are used for, the things they have in common and their differences.

How to configure the properties of the transaction object's data group so that its associated data provider can obtain information from other data sources.

Previously, we have seen how to associate a Data Provider with a transaction to populate it with data. Now we see that the Data Provider can be used to retrieve the transaction’s information from other data sources. As a result, the transaction will have no associated tables and will behave as a "view" of the database.

Review of the events available at the transaction level, and solution of a new requirement that allows coding the After Trn event.

In this video, we will try to analyze different topics related to transaction design and how the decisions we make are reflected in the database structures created, or in the application's functionality. Unlike previous videos on this topic where we developed an example, in this one we will address specific cases that allow us to analyze different practical situations that can be useful in building our solution.

There is a database server and its client, which is the program on the application server. Every query is started on the client, and may or may not be entirely resolved on the database server, which will impact performance.

Starting from the general syntax of the For each, every part is reviewed with clarifying examples, in order to obtain a synthetic and integrated view that is valid for other forms of queries (groups of Data Providers, grids with a base table, Data Selectors).

We will see ways to manage and customize different types of paging: the one generated automatically by the Work With For Web Pattern of a transaction, one generated manually for a Web panel grid, that of a For Each command or a Data Provider group with a base table.

In the video "Default Design System" of the CORE course, grid paging was already shown.

The developer writes order clauses (conditional or not) that are optimized by the GeneXus specifier when possible. However, this ultimately depends on the DBMS. We explore the topic with examples.

This clause of the For each (also of Data Providers and Grids) allows processing only records that are different according to some of their attributes. When and how to use it. Examples and restrictions.

How the base table of a for each (or other type of query) is determined when no base transaction is specified. The case of nested for eachs is also analyzed.

Formalization of the 3 cases of nested For each commands: Join, Cartesian Product, and Control Break. Also, their possibilities are explored in depth. Examples: what happens when there is a 1 to N relationship through subtypes; what happens if attributes that can only be reached from the main For each are placed in the nested one.

This case study reviews everything a 2-level transaction executes when trying to insert data through its business component. It also addresses how to condition rules and events to be executed only for the web or only for BC. Some considerations about methods and error messages.

It continues the case study of part 1, and reviews everything a 2-level transaction executes when updating through its business component and when making a deletion. In addition, it discusses how to work with the lines in the BC and the errors that may occur.

The following methods are mentioned: Success, Fail, Load, GetbyKey, RemoveByKey, new.

We study the case of a batch insertion through a Business Component and make it more complex to do an Update if there is a record or an Insert otherwise, for each instance to be handled. We also show the highest-level solution to load the BC with a Data Provider.

Differences between methods for working with the database (Load, Insert, Update, Save, direct primary key assignment, InsertOrUpdate) are introduced and discussed, and an example of using a Data Provider to load data is presented.

Watching the video "Single-Level and Two-Level Business Components. Comparison" is recommended.

An in-depth analysis is made of what the developer must do to update through a (two-level) BC variable and what GeneXus does in the background. All possibilities are considered.

The following methods are used: Load, Update, Save, Remove, RemoveByKey, GetByKey

Based on the theoretical analysis in the video "Update with Business Component. Behind the Scenes," this video shows practical examples of updating a two-level BC, including all the possibilities.

It shows how to update when a variable is in Update mode and how to update when it is in Insert mode. In addition, the case of loading through a Data Provider is shown.

GeneXus objects of Transaction and Procedure type provide the Commit on Exit property that can take the value Yes or No. This determines whether the generated programs will execute an automatic Commit or not. This video shows examples that explain this behavior. The concept of Isolation Levels to control data read is also presented, as well as concurrency control.

What happens when more than one user tries to access the database simultaneously?

Introduction of the Query object and its structure and main concepts. Step by step explanation on the building of a couple of queries viewed in runtime through graphs in web panels.

Two examples of use of Query objects are presented, receiving parameters and modifying the query output format at runtime.

Object for displaying in a web panel the indicators that allow for a disaggregated analysis of information (Key Performance Indicators).

We have to design a web and native application for a travel agency. How do we express the screen design in GeneXus with the new Design System object? In this charla we will build a solution in a few minutes, modeling the design in GeneXus. The main objective is to present this innovation, a new way to model design that is incorporated into GeneXus to reduce the gap between designers and developers. Everything is about the general background that applies to the entire GeneXus philosophy: how to express the maximum by saying the minimum.

Many times it is necessary to access data that are not stored in the database of our application. Here is an introduction to the possible methods that will be developed in the following videos.

Many times we need to access external databases. To this end, GeneXus offers a reverse engineering process that allows solving everything necessary to do so. An example is given here, and the necessary concepts are introduced.

In this video, we briefly review how to publish and consume web services with GeneXus. In the following videos on this topic, we will focus on advanced topics that provide more flexibility when using web services.

In this video, we will focus on publishing, testing, and customizing SOAP services with GeneXus by assigning a namespace, or including more than one method in a single web service.

In this video, we will show an example of publishing a REST service using the API object and the advantages it offers, since it adds an intermediate layer that separates the interface from the implementation details. In this way, future programming changes in the objects do not affect the way they are invoked by external applications.

In this video, we will see how to test a SOAP service published with GeneXus from GeneXus itself, importing it as an external object. Then we will focus on security, tracing, and routing considerations, which allow a service consumer to indicate the endpoint to which the service should send its response in an invocation. In addition, how to change the location of a service and how we can get the result of an invocation and handle errors.

In this video, we will see an example of consuming an OpenApi REST service from a public API from GeneXus. In addition, how to consume a secure REST service and how to customize the way it is consumed by invoking HTTP methods (Get, Post, Put, Delete) using a variable of HttpClient type, processing the status code resulting from the operation performed.

When receiving changes made by other developers, conflicts may arise. This video shows what a conflict is and the times at which they might be produced, with possible solutions.