Official Content
  • This documentation is valid for:

Once a new Knowledge Base is created, the next step is to describe the users’ visions. To do so, it is necessary to identify real-life objects (it is recommended to pay attention to the nouns that users mention in their descriptions, such as: products, invoices, customers, etc.) and start defining them by using GeneXus objects.

GeneXus developers don’t work on low-level tasks such as defining tables, normalizing, designing programs, programming, and the like. Instead, their work is a higher-level activity that implies describing the reality of users. After that, GeneXus analyzes the defined objects and goes on to design the database and the application programs for the selected platform in a totally automatic manner.

Consider the case where the pharmacy requesting the application wants to be able to record the products they have on sale, saving each product's code, name, sale price, and available stock. 

To describe each identified real-life object, you have to create a GeneXus object of the Transaction type, where each attribute corresponds to the information you want to record.

How to create a Transaction object to describe the Products

In addition to creating and defining the Transaction object manually, GeneXus Next also provides Nexa to help you create it. So, select GeneXusNext-AI Assistant Icon in the right window to open Nexa, and type your instruction in the "Ask me a question..." input box. For example, write:

I need to insert, update, and delete several products. For each one it is necessary to store its code, name, sale price, and stock.

Nexa will show a response similar to the following:

The "Product" Transaction has been successfully created in the "Root Module." This Transaction includes the attributes: ProductCode (as primary key), ProductName, ProductSalePrice, and ProductStock. You can now use this Transaction to insert, update, and delete products as needed. If you have any further questions or need additional assistance, feel free to ask!

The following image shows the "Product" transaction created as a result of the order to Nexa. It hasn't been saved yet. If you find its definition appropriate, you can save it (CTRL+S); otherwise, you can edit it and then save.

GeneXus Next first objects - Product transaction created

Each Transaction object contains several selectors.

Both Source and Structure selectors allow defining the attributes or fields that describe the object of reality (in this case, a product). You can choose to use the one that is more convenient for you. More experienced developers probably prefer to use the Source selector, while newer ones prefer to use the Structure selector. The definitions made through the Source selector are reflected in the Structure selector and vice versa.

Below you can see the Structure selector corresponding to the Product Transaction object:

GeneXus Next first objects - Product transaction structure

Note that the first attribute in the Structure has a key icon. This shows it’s the unique identifier or primary key for the Transaction. Every Transaction object requires a primary key attribute or a combination of attributes to uniquely identify each record. For example, in this Product Transaction, the primary key is the ProductCode attribute. This ensures that users cannot register multiple products with the same identifier, thus maintaining data integrity.

Note: The key icon shown in the Structure selector corresponds to the asterisk (*) shown in the Source selector.

Attribute naming convention

Attribute names follow a naming convention. Each attribute name must start with the name of the Transaction (in this case, “Product”), followed by the concept it represents. As a result, the attributes in this example are ProductCode, ProductName, ProductSalePrice, and ProductStock. This naming convention helps in understanding which object each attribute refers to.

Attribute data types

When defining each attribute, its data type must be indicated (for example, Numeric, Character, Image, etc., depending on the type of information it stores). In this example, the attributes were defined by Nexa. You can change an attribute’s definition using your preferred editor (Structure or Source).

Defining a domain

Since you may need to define more prices when the pharmacy buys or sells products, being able to make a generic definition for all prices would help.

To do this, if you are working in the Structure selector, go to the line where the ProductSalePrice attribute is defined, and in the Type column, add "Price" followed by the equal sign before the data type.

GeneXus Next Domain creation in Structure

The attribute ProductSalePrice is defined based on the Price data type. This data type definition, called Price, with 10 digits and 2 decimals, is called a Domain.

You may view the created domains in the Knowledge Base by selecting View > Domains in the main menu. Then, when you click on a certain domain, the Properties window is refreshed showing the properties that can be configured for that domain. In addition to setting the data type for a domain, you can also set other interesting properties for it.

So, the Price domain is already defined in the Knowledge Base, it is assigned to the ProductSalePrice attribute and it can be assigned to other attributes that share the same definition.

Note: If you are working in the Source selector of a Transaction object, and you want to define the same Price domain, the syntax is as follows: ProductPrice [DataType = "Price=Numeric(10.2)"].

Transaction Web Layout

Now select the Product Transaction Web Layout selector. 

Note that GeneXus Next has automatically designed a Web Layout according to the attributes defined in this Transaction. 

This Web Layout will enable users to add, update, and delete products at runtime. It will look slightly different, but more attractive.

Modeling more requirements

Suppose that the pharmacy also needs to record the product type associated with each product (to know whether it is a medicine, cosmetic, baby care item, etc.).

You can use again Nexa to solve this requirement. To do so, in the "Ask me a question..." input box, type your instruction. For example, write:

I need to record the type of product associated with each product.

Nexa will show a response similar to the following:

The necessary changes have been made:

A new "ProductType" Transaction has been created with attributes ProductTypeCode (as primary key) and ProductTypeName.

The existing "Product" Transaction has been updated to include a reference to ProductTypeCode, establishing a relationship with the "ProductType" Transaction.

Now, each product can be associated with a specific product type. If you have any further questions or need additional modifications, feel free to ask! 

The following image shows the ProductType Transaction object created:

GeneXs Next - ProductType transaction Structure

Also, the Product Transaction object was updated as shown below:

GeneXus Next - Product Type structure

ProductTypeCode is the identifier attribute in the ProductType Transaction (more specifically, it is the primary key of that Transaction). So, when a primary key is included in another Transaction, GeneXus understands that there the attribute has the role of the foreign key.

The ProductTypeName attribute is also present in both Transactions. However, it is not marked as the identifier of any of the defined Transactions. Therefore, GeneXus will take it as a secondary attribute. GeneXus will then include ProductTypeName in the ProductType physical table that it will create in the database and not in the Product physical table.

The definitions are reasonable (enter each product type only once in a single location, and then, for each product, reference the corresponding product type). Proceed to save.

Note: The Transaction concept and the physical table concept are not the same. Keep in mind that Transaction is the GeneXus object that you create in the Knowledge Base to represent an object of reality. GeneXus considers the attributes present in each Transaction object and analyzes the attributes' names while also taking into account some properties. In addition, it determines the physical tables that it must create in the database, and which attributes it must store in each table.

 

Last update: June 2025 | © GeneXus. All rights reserved. GeneXus Powered by Globant