AI-Powered XtraReports in XAF: Unlocking DevExpress Enhancements

AI-Powered XtraReports in XAF: Unlocking DevExpress Enhancements

Today is Friday, so I decided to take it easy with my integration research. When I woke up, I decided that I just wanted to read the source code of DevExpress AI integrations to get inspired. I began by reading the official blog post about AI and reporting (DevExpress Blog Post). Then, as usual, I proceeded to fork the repository to make my own modifications.

After completing the typical cloning procedure in Visual Studio, I realized that to use the AI functionalities of XtraReport, you don’t need any special version of the report viewer.

The only requirement is to have the NuGet reference as shown below:


    <ItemGroup>
        <PackageReference Include="DevExpress.AIIntegration.Blazor.Reporting.Viewer" Version="24.2.1-alpha-24260" />
    </ItemGroup>
    

Then, add the report integration as shown below:


    config.AddBlazorReportingAIIntegration(config =>
    {
        config.SummarizeBehavior = SummarizeBehavior.Abstractive;
        config.AvailableLanguages = new List<LanguageItem>
        {
            new LanguageItem { Key = "de", Text = "German" },
            new LanguageItem { Key = "es", Text = "Spanish" },
            new LanguageItem { Key = "en", Text = "English" },
            new LanguageItem { Key = "ru", Text = "Russian" },
            new LanguageItem { Key = "it", Text = "Italian" }
        };
    });
    

After completing these steps, your report viewer will display a little star in the options menu, where you can invoke the AI operations.

You can find the source code for this example in my GitHub repository: https://github.com/egarim/XafSmartEditors

Till next time, XAF out!!!

Test Driving DevExpress Chat Component

Test Driving DevExpress Chat Component

If you’re a Blazor developer looking to integrate AI-powered chat functionality into your applications, the new DevExpress DxAIChat component offers a turnkey solution. It’s designed to make building chat interfaces as easy as possible, with out-of-the-box support for simple chats, virtual assistants, and even Retrieval-Augmented Generation (RAG) scenarios.

The best part? You don’t have to start from scratch—DevExpress provides a range of pre-built examples, making it easy to get started and customize to your needs. Whether you’re aiming for a basic chatbot or a more complex AI assistant, this component has you covered.

To use the examples you can use any open A.I compatible service like Ollama, Open A.I and Azure OpenAI, in current devexpress example they use Azure like this

using DevExpress.AIIntegration;
...
string azureOpenAIEndpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT");
string azureOpenAIKey = Environment.GetEnvironmentVariable("AZURE_OPENAI_API_KEY");
string deploymentName = "YourModelDeploymentName"
...
builder.Services.AddDevExpressBlazor();
builder.Services.AddDevExpressAI((config) => {
    config.RegisterChatClientOpenAIService
        new AzureOpenAIClient(
            new Uri(azureOpenAIEndpoint),
            new AzureKeyCredential(azureOpenAIKey)
        ), deploymentName);
    //or call the following method to use self-hosted Ollama models
    //config.RegisterChatClientOllamaAIService("http://localhost:11434/api/chat", "llama3.1");
});

I tested with OpenA.I  API instead of azure, so my code looks like this

string azureOpenAIEndpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT");
string azureOpenAIKey = Environment.GetEnvironmentVariable("AZURE_OPENAI_API_KEY");

string OpenAiKey= Environment.GetEnvironmentVariable("OpenAiTestKey");

builder.Services.AddDevExpressBlazor();
builder.Services.AddDevExpressAI((config) => {
    //var client = new AzureOpenAIClient(
    //    new Uri(azureOpenAIEndpoint),
    //    new AzureKeyCredential(azureOpenAIKey));
    //Open Ai models ID are a bit different than azure, Azure=gtp4o OpenAI=gpt-4o
    var client = new OpenAIClient(new System.ClientModel.ApiKeyCredential(OpenAiKey));
    config.RegisterChatClientOpenAIService(client, "gpt-4o");
    config.RegisterOpenAIAssistants(client, "gpt-4o");
});

 

Notice the IDs of the models in Azure and Open A.I are different

  • Azure=gtp4o
  • OpenAI=gpt-4o

This are the URLs for the different example

  • Chat : https://localhost:53340/
  • Assistant/RAG: https://localhost:53340/assistant
  • Streaming: https://localhost:53340/streaming

I’m super happy that DevExpress components are doing all the heavy lifting and boilerplate code for us, I have developed the same scenarios using semantic kernel even when there is not so much code to write you still have the challenge of develop a responsive U.I

For more information and to see the examples in action, check out the full article.

Replacing WCF with AspNetCore Rest API as transport layer for XPO

Replacing WCF with AspNetCore Rest API as transport layer for XPO

I have been using XPO from DevExpress since day one. For me is the best O.R.M in the dot net world, so when I got the news that XPO was going to be free of charge I was really happy because that means I can use it in every project without adding cost for my customers.

Nowadays all my customer needs some type of mobile development, so I have decided to master the combination of XPO and Xamarin

Now there is a problem when using XPO and Xamarin and that is the network topology, database connections are no designed for WAN networks.

Let’s take MS SQL server as an example, here are the supported communication protocols

  • TCP/IP.
  • Named Pipes

To quote what Microsoft web site said about using the protocols above in a WAN network

https://docs.microsoft.com/en-us/sql/tools/configuration-manager/choosing-a-network-protocol?view=sql-server-2014

Named Pipes vs. TCP/IP Sockets

In a fast-local area network (LAN) environment, Transmission Control Protocol/Internet Protocol (TCP/IP) Sockets and Named Pipes clients are comparable with regard to performance. However, the performance difference between the TCP/IP Sockets and Named Pipes clients becomes apparent with slower networks, such as across wide area networks (WANs) or dial-up networks. This is because of the different ways the interprocess communication (IPC) mechanisms communicate between peers.”

So, what other options do we have? Well if you are using the full DotNet framework you can use WCF.

So, it looks like WCF is the solution here since is mature and robust communication framework but there is a problem, the implementation of WCF for mono touch (Xamarin iOS) and mono droid (Xamarin Android)

You can read about Xamarin limitations in the following links

Android: https://docs.microsoft.com/en-us/xamarin/android/internals/limitations

iOS: https://docs.microsoft.com/en-us/xamarin/ios/internals/limitations

I don’t want to go into details about how the limitation of each platform affects XPO and WCF but basically the main limitation is the ability to use reflection and emit new code which is needed to generate the WCF client, also in WCF there are problems in the serialization behaviors.

Well now that we know the problem is time to talk about the solution. As you know XPO has a layered architecture ( you can read about that here https://www.jocheojeda.com/2018/10/01/xpo-post-5-layered-architecture/)

So basically, what we need to do is to replace the WCF layer with some other technology to communicate to the database server

The technology I’ve selected for this AspNetCore which I would say is a really nice technology that is modern, multi-platform and easy to use. Here below you can see what is the architecture of the solution

AspNetCore

Rest API

So, what we need basically is to be able to communicate the data layer with the data store through a network architecture.

The network architecture that I have chosen is a rest API which is one of the strong fronts of AspNetCore. The rest API will work as the server that forward the communication from XPO to the Database and vice versa, you can find a project template of the server implementation here https://www.jocheojeda.com/download/560/ this implementation references one nuget where I have written the communication code, you can fine the nuget here https://nuget.bitframeworks.com/feeds/main/BIT.Xpo.AgnosticDataStore.Server/19.1.5.1

Also we need a client that is able to interpret the information from the rest API and feed XPO, for that I have created a special client you can find here https://nuget.bitframeworks.com/feeds/main/BIT.Xpo.AgnosticDataStore.Client/19.1.5.1

The client implementation has been tested in the following platforms

  • Xamarin Android
  • Xamarin iOS
  • Xamarin WPF
  • DotNetCore
  • DotNetFramework

The client implementation has been tested in the following operative systems

  • Android 5 to 9
  • iOS 9 to 11
  • MacOS: Sierra to Catalina
  • Windows 10

In this link, you can see a full implementation of the server and the clients (XAF and Xamarin)

What is next? Well here are a few topics for the upcoming posts

  • Understanding JWT tokens
  • How to secure your data store service with a JWT token
  • Hosting multiple data store with a single service
  • Implementing your own authentication method
  • Examples examples examples

 

Exposing your XPO ORM using GraphQL dotnet

Exposing your XPO ORM using GraphQL dotnet

Exposing your XPO ORM using GraphQL

Note: you can download the full source code for this article in my GitHub repository 

In the past few years, I have been working on developing mobile applications, in the mobile world most of the applications will consume some type of data service, the main problem here is how to choose the correct data service? There are a lot of technologies to expose data over the wire and all of them are good somehow, so for me, the quest is about to find a technology where can I use my current skill set.

Today subject of study is GraphQL, an open source technology developed by Facebook that is a data query and manipulation language for API.

The beauty of GraphQL is its efficient and flexible approach to develop web APIs that can be queried to return a different data structure in the opposite side of the REST API and traditional web services that return a fix data structure, you can learn more about the GrahpQL project on their website https://graphql.org/

First, we will start by creating a new Asp.net core web application

A screenshot of a cell phone Description automatically generated

We name the application

A screenshot of a cell phone Description automatically generated

Then we select Empty for the project type

A screenshot of a cell phone Description automatically generated

Now that the project is created, we need to add a few NuGet packages, you can copy and paste the following snippet inside of your csproj file

<ItemGroup>

<PackageReference Include="DevExpress.Xpo" Version="18.2.7" />

<PackageReference Include="GraphQL" Version="2.4.0" />

<PackageReference Include="GraphQL.Server.Transports.AspNetCore" Version="3.4.0" />

<PackageReference Include="GraphQL.Server.Transports.WebSockets" Version="3.4.0" />

<PackageReference Include="Microsoft.AspNetCore.App" />

<PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All" />

<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />

<PackageReference Include="Microsoft.Data.Sqlite" Version="2.2.4" />

<PackageReference Include="System.Reactive" Version="4.1.5" />

</ItemGroup>

 

Now if let’s try to compile and run the application, at this moment you should see a “hello world” in your browser

A screenshot of a cell phone Description automatically generated

Now let’s add a second project to the solution to host the ORM, for that let’s use a NetStandard class library

A screenshot of a cell phone Description automatically generated

Let’s name the project XpoOrm, then edit the project file and add the following NuGet packages

<ItemGroup>

<PackageReference Include="DevExpress.Xpo" Version="18.2.7" />

<PackageReference Include="GraphQL" Version="2.4.0" />

<PackageReference Include="GraphQL.Server.Transports.AspNetCore" Version="3.4.0" />

<PackageReference Include="GraphQL.Server.Transports.WebSockets" Version="3.4.0" />

<PackageReference Include="System.Reactive" Version="4.1.5" />

</ItemGroup>

 

Now let’s add 3 folders, schema, services and models

A close up of a logo Description automatically generated

The basic structure of our project is ready, so let’s start adding some models, we will add 2 models products and categories, you can get the source of the files here

A screenshot of a cell phone Description automatically generated

A screenshot of a cell phone Description automatically generated

When you finish implementing the models the next step is to implement the services, remember that the main goal of GraphQL is to create a queryable layer between the client and the data service, you can architecture your service in the way that is more convenient for you but in this case I will create one service per entity, this services will be injected in our application using asp.net dependency injection. You can find the source for the services here

Product Service

A screenshot of a cell phone Description automatically generated

Category Service

A screenshot of a cell phone Description automatically generated

So far there we have not written any code related to GraphQL so now it’s the time. GraphQL does not directly expose your data model class instead it builds a type based on your model, let’s see how this will work for the Category model

A screenshot of a cell phone Description automatically generated

As you can see, I have created a new class that inherits from ObjectGraphType<T> where T is our XPO persistent class. Also, in the constructor I used the fluent API to map the fields from the category model to the CategoryType class, the method Field contains several overloads so you can do any type of crazy stuff in here, but for now I’m going keep it simple, now lets create the type for the product model.

A screenshot of a cell phone Description automatically generated

Now that we have created the ProductType class we can see that there are new characteristics here, the first new thing that you will notice is that in the constructor I injected the category service to load the category object related to the product, that is the common design pattern of GrahpQL, this approach is  useful if you are using POCO objects. Also, if you see the commented-out code you can see that when we use XPO we don’t need to inject the category service since it can be loaded directly from the instance of the Product class using XPO lazy loading feature. You can find both graph types here

Now that we have our graph types, we need to create 2 more classes, an object that will hold our list of queries and a schema object that will provide information about the types and the queries that we are exposing, let’s start with the queries object

A screenshot of a cell phone Description automatically generated

The Queries object is basically another graph type, but instead of exposing a model class is exposing the object class, it also uses the dependency injection to inject the 2 services that will forward the data to the fields. Now its time to create the schema for our GraphQL service

A screenshot of a cell phone Description automatically generated

A GraphQL schema can only expose one query so that is why I have created the object queries to hold all the possible subqueries of our services. As you can see, I injected the queries object and the dependency resolver, you can find the code for these classes here.

Now its time to go back to the asp.net core service and start the configuration of GrahpQL, let’s start with the program class

A screenshot of a cell phone Description automatically generated

As you can see in the main method there is some boilerplate code to initialize XPO data layer and create some sample data, nothing new if you are an XPO user you might be already familiar with this code. Now let’s move to the startup class

A screenshot of a cell phone Description automatically generated

As any asp.net core web application, there are 2 important methods let’s see what happened on each of them.

In the configure services method I register the services I created and the graph types also added the GraphQL service and the web sockets and data loader.

Now in the configure method I enabled the use of default files and static files, web sockets also I exposed the GrahpQL schema using web sockets and GrahpQL (this is the HTTP version of the API)

Our API is almost done, there is only one last step we need to do, we need a way to test our API for that we will use Graphical which is a web client to query GrahpQL APIs, the graphical project is hosted here https://github.com/graphql/graphiql but to make it simpler you can download the files from my GitHub repository here

Let’s create a wwwroot folder and add the graphical files into it

Run the application, you should see the graphical U.I and you should be able to navigate the API documentation

A screenshot of a social media post Description automatically generated

or you can query of XPO ORM

A screenshot of a social media post Description automatically generated

As you can see there is autocomplete on the query editor also we are able to query objects and nested objects on a field-based manner

This article is the first article on a series of how to expose any XPO ORM using GraphQL, in the next post we will learn about mutations

XPO para Xamarin Forms, May 15 2019 (Lenguaje Español)

XPO para Xamarin Forms, May 15 2019 (Lenguaje Español)

En el seminario web, aprenderá a aprovechar los conocimientos existentes de XPO y a usarlos para desarrollar aplicaciones móviles con Xamarin Forms

Fecha

Miercoles 15, 2019, 10:00 A. M hora de los Angeles (UTC-7)

Duracion

3 Horas

Lenguaje

Español

¿Qué obtendrá después del webinar?

  • Acceso al repositorio privado de GitHub con ejemplos de código para cada tema
  • La sesión de Webinar grabada

Lista de temas

  1. Instalación de XPO para Xamarin Forms (Android e iOS)
  2. Inicializar la base de datos local y el esquema
  3. Conexiones locales con SQLite: instalación de paquetes necesarios para Android e iOS
  4. Conexiones locales con XML: creación de un archivo XML base
  5. Conexiones remotas: conexión de base de datos directa con TCPIP (red LAN)
  6. Conexiones remotas: la capa de acceso a datos de WCF
  7. Inicializar la capa de datos
  8. Enlace (binding) de datos MVVM
  9. Enlace de propiedades primitivas
  10. Enlace de propiedades de navegación
  11. Cargando colecciones (la forma tradicional)
  12. Cargando colecciones asincrónicas
  13. Cargando un solo objeto de forma asíncrona
  14. Las paginaciones en colecciones
  15. Como reducir la carga de datos con XPView
  16. Colecciones observables con BIT. Xpo. observables

Requisitos previos

  • Comprensión básica de Xamarin Forms
  • Comprensión básica del patrón de diseño MVVM
  • Conocimiento básico de XPO

Precio

€99,00 EUROS

[wpecpp name=”xamarin xpo es” price=”99.00″ align=”left”]

Nota

Si está interesado en este curso o tiene alguna duda póngase en contacto con nosotros en training@bitframeworks.com

 

Migrating XAF projects to the new version of csproj (SDK project VS2017)

Migrating XAF projects to the new version of csproj (SDK project VS2017)

For a while now I have been trying to create a framework for XAF (yes I know XAF is already a framework) but it was too difficult to handle the different version of XAF and upgrade the solution from version to version.

Luckily for me, DevExpress team decided to publish all their DLLs as nuget packages, you can learn more about that here. But there was still one problem for me, at that time they did not include the nugets for XAF, later that year (2018) they decided to publish the nugets for XAF, you can read about it here

Now I have all the pieces to create the project template for the modules of my framework, at least that is what I thought, there was still one more stone in my path and it was the csproj file. At this moment (version 18.2.x) XAF project templates are based on visual studio 2015 project format, so the way the projects handles nuget references is based on the old standard packages.config, another problem is that if you want to package your module as a nuget you have to use the old package.nuspec.

So let’s migrate our XAF module project to the new version of csproj, but first take a look to the old version of the file in the image below

 

Once you have a XAF solution open on visual studio these are the steps to do the migration

1) Right click on your module file and select “Unload Project”

2) Now that the project us unloaded it will appear unavailable in the solution explorer, so we can right click over it and select “edit”

4) Delete all the content of your csproj and replace it with this XML, you can also change the version of nuget files, in this case, I’m using 18.2.6


<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net452</TargetFramework>
    <GenerateAssemblyInfo>true</GenerateAssemblyInfo>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="DevExpress.ExpressApp.Security.Xpo" Version="18.2.6" />
    <PackageReference Include="DevExpress.ExpressApp.Validation" Version="18.2.6" />
    <PackageReference Include="DevExpress.Persistent.BaseImpl" Version="18.2.6" />
  </ItemGroup>

  <ItemGroup>
    <Folder Include="Properties\" />
  </ItemGroup>
</Project>

5)Delete the file AssemblyInfo.cs from the properties folder

 

Congratulations you have successfully migrated your csproj file

Now some advantages and disadvantages of this new csproj format

Advantages
  1. Smaller project file easy to edit
  2. improved usage of nuget packages
  3. its easier to pack your module as a nuget
Disadvantages
  1. You can not use the Devexpress add item context menu because it will add references to local assemblies
  2. The module designer stop working so you have to do all your module configuration in code