Development of a new functionality integrated in the PATIO Pro Application of 4TPM

Abstract

DESARROLLO DE UNA NUEVA FUNCIONALIDAD INTEGRADA EN LA APLICACIÓN PATIO PRO DE 4TPM Autor: Nadal, Jean. Director: Thierry, Eric. Entidad Colaboradora: 4TPM RESUMEN DEL PROYECTO El departamento de valores es un servicio ofrecido por bancos y demás instituciones financieras que se encarga de la gestión de todas las operaciones relativas a la negociación de un activo financiero. Se trata de un entorno en permanente evolución debido particularmente al aumento del uso de la informática. Esta transformación se caracteriza también por la aparición de nuevos instrumentos financieros cada vez más sofisticados y a un aumento de la gama de servicios que ofrece este departamento lo que requiere de un uso cada vez más importante de herramientas informáticas. Debido a esta digitalización y a la creciente complejidad, el sector financiero demanda cada vez más ingenieros y pide a sus trabajadores que dispongan de nociones de programación y de informática en general para entender sus estrategias y programas. Es por lo tanto cada vez más habitual cruzarse con un gran número de ingenieros que desempeñan diferentes empleos en empresas del sector financiero. En este entorno se incluye este proyecto de fin de carrera, nacido a partir de unas prácticas de una duración de 5 meses realizadas en 4TPM, empresa francesa de software para trading y gestión de carteras. Son los desarrolladores de la plataforma PATIO utilizada por bancos y sociedades de gestión de carteras y el proyecto se realiza en su equipo de desarrollo. Una de las funcionalidades que permite PATIO a sus usuarios es la de ejecutar órdenes a mercado en bloque. Esto permite a un gestor ejecutar una sola orden en la que se realizan varias acciones para varios de sus clientes. Este tipo de ordenes genera una tarea compleja que PATIO trata de forma asíncrona. Las tareas llegan a unos servidores que en función de su complejidad van a dividirla, o no, en un número variable de subtareas que van a asignar posteriormente a otros servidores para ejecutarlas. Se trata de un proceso complejo lo que dificulta, en el caso de que haya un problema, saber en qué momento y en que servidor se ha producido el fallo. Hasta ahora, cuando un cliente tiene un problema, el equipo de soporte busca manualmente el momento y servidor en el que se ha producido. Para eso tienen que buscar en los denominados logs de las tareas asíncronas. Los logs son unos ficheros que contienen el registro de todos los acontecimientos de un proceso. Esto permite analizar paso a paso la actividad interna del proceso al igual que sus interacciones con su entorno. Debido a su complejidad esta búsqueda requiere tiempo y no siempre es posible en particular cuando los servidores se hallan en las oficinas de los clientes y que no se tiene acceso directo a los logs. Hoy en día, las empresas buscan aumentar su efectividad mediante, por ejemplo, el aumento de la agilidad y rapidez de sus procesos internos y de los servicios que ofrecen. Una forma de aumentar dicha efectividad es mediante la automatización informática de procesos que anteriormente se realizaban a mano. Esto permite una reducción de tiempo considerable debido a la inmensa capacidad de cálculo que tienen hoy en día los ordenadores. La motivación principal para llevar a cabo este proyecto es por lo tanto la de automatizar un proceso interno que es largo, tedioso y no siempre posible. Esto va a permitir reducir el proceso de búsqueda de los logs a cero y convertirlo en algo inmediato. De este modo se podrá encontrar rápidamente el fallo y resolver el problema del cliente que es al fin y al cabo lo más importante en este tipo de situaciones. La estructura del proyecto es de tipo cliente – servidor y se divide en dos funciones diferentes presentes en ambas partes. La primera función, Display, permite obtener toda la información relativa a las tareas, subtareas y servidores asíncronos. La función Monitor se usa para ver de forma inmediata el estado de los servidores al igual que de las tareas y subtareas. A continuación se muestra un esquema en el que se entiende la relación que hay entre las diferentes partes que forman la plataforma PATIO, sus conexiones con el entorno y en qué partes se integra el proyecto.

Figura 1: Arquitectura de la plataforma PATIO La parte BACKEND representa la parte servidor en la cual se han añadido y modificado ciertos archivos en C que se encargan de realizar las consultas SQL a las tablas de servidores, tareas y subtareas. Por otro lado la parte FRONTEND es la parte cliente donde se han añadido un número importante de clases. Esto se debe a que en esta parte ha sido necesaria la creación de toda la estructura al ser, en el contexto de este proyecto, la primera vez que se han manipulado datos relativos a servidores, tareas o subtareas asíncronas en los servicios web de la empresa. Esta parte, escrita en JAVA, permite la realización de la interfaz con la que el usuario va a realizar las consultas que desee al igual que se encarga de la comunicación con el servidor. El proyecto empezó con el desarrollo de la función Display que, al ser más complicada y completa, permite entender desde el comienzo el funcionamiento de la comunicación de la estructura cliente – servidor de la empresa. Se desarrolla en primer lugar la parte servidor, encargada de crear la consulta a la base de datos con la información que le llega del cliente. Esta parte se escribe en lenguaje C y siguiendo un planteamiento bottom up es decir empezando por abajo, en este caso la base de datos, para llegar finalmente a la comunicación con el cliente. Hay que añadir ciertas funciones y estructuras a los archivos ya existentes que gestionan las acciones relativas a las tareas, async_task.c, las subtareas, async_subtask.c, los servidores, async_registration.c y sus

respectivos archivos de cabecera. En cada caso las modificaciones son muy parecidas y van orientadas a añadir la opción de realizar consultas a su tabla en la base de datos respectiva. En los archivos de cabecera se añade una estructura con el objetivo de almacenar la información que llegue desde el cliente y poder crear la consulta en base a dicha información. En esta estructura se definen las mismas variables que tiene la tabla a la que se hará la consulta, de forma que se podrán hacer consultas filtrando con cualquier variable de la tabla. En los archivos .c se añade en primer lugar un tipo de estructura que va a permitir la codificación de las variables definidas anteriormente, a la hora de enviar la información al cliente, y la descodificación de dicha información cuando se reciba. Este procedimiento ya existía y se realiza en todos los archivos del servidor de la empresa. A continuación se añaden las 3 funciones siguientes en cada uno de los archivos. La primera es async_nombre_de_la_tabla_from_objetrequest donde, en función del tipo de consulta, que en nuestro caso es de tipo lectura, asocia el código mess_tag y el ID de la tabla y realiza la llamada a la segunda función, async_nombre_de_la_tabla_server_process. Esta función se encarga de identificar el tipo de consulta y de llamar a la función encargada de realizar la acción. En este caso son consultas de lectura por lo que se hace la llamada a la tercera función, async_nombre_de_la_tabla_server_read. Se trata de la función más importante puesto que es en ella donde se analiza la consulta del cliente, se crea la consulta SQL a la base de datos, se envía, se almacena el resultado de dicha consulta y finalmente se envía de vuelta al cliente la información solicitada. A continuación se muestra la consulta SQL que se crea en el caso de que la información recibida proveniente del cliente sea el estado y la fecha de creación de una tarea asíncrona: SELECT * FROM ASYNC_TASK WHERE DTCREAL = “fecha de creación” AND STATUSI = “estado” Esta es la dinámica general en la que se basa el servidor para esta función, sin embargo hay ciertas diferencias particularmente en la función server_read y en la manera en que se crean las consultas SQL entre los archivos async_task, async_subtask y async_registration. Esto se debe simplemente a que la información que contienen sus respectivas tablas es diferente. Una vez el servidor realizado se puede empezar la parte cliente. Para esta parte ha sido necesaria la creación de nuevos archivos. Esto se debe a que hasta el momento, no había ningún tránsito de información sobre los servidores, tareas o subtareas entre el servidor y los servicios web por lo que es necesario crear toda la estructura en la parte cliente. Lo primero que hay que crear son las APIJAVA, que se encargan de la comunicación con el servidor. Se requiere de la creación de 6 clases, una para cada tipo de dato (servidor, tarea y subtarea) y su respectiva clase que gestiona la consulta. En el primer grupo se definen las variables que componen su respectiva tabla. En las clases de consulta se definen las variables con las que se puede filtrar, en este caso son las mismas que las que componen la tabla de modo que potencialmente se puede filtrar gracias a cualquiera de las variables de su tabla. Además de esto se añaden dos funciones, la primera construirá la consulta con los parámetros introducidos por el usuario. La segunda función crea la socket que une al servidor, realiza la llamada a la función anterior, y recibe el resultado del servidor.

Las capas superiores sin ser más complejas de programar, si requieren de un número muy importante de clases. Estos se debe a que en muchos casos es necesaria la realización de una clase para cada tipo de objeto, obteniendo de esta forma tres clases muy similares que realizan la misma acción en el caso de las tareas, subtareas y servidores. A continuación se explica la utilidad de dichas clases centrándose únicamente en aquellas que se encargan de lo relativo a las tareas asíncronas. Lo primero que se debe hacer es crear un objeto en el que se definen las variables de la tabla de tareas, no es obligatorio que tengan el mismo nombre que en las APIJAVA puesto que es necesaria la creación de una clase que haga de adaptador asociando el contenido de las variables de tipo APIJAVA con el de las variables de esta clase. En este caso también se crea una clase de tipo consulta en la que únicamente se definen las variables con las que el usuario puede filtrar su búsqueda. En el caso de las tareas se ha escogido el estado, el usuario que creó la tarea, la fecha de creación y las horas de inicio y de fin. A continuación se crean un grupo de clases que permiten la apertura de la funcionalidad en la plataforma, un editor para la ventana de parámetros y otro para la de resultados. La primera clase es muy básica y simplemente se especifica el nombre del editor y el de la función. La segunda es de las más importantes puesto que hay que escribir toda la parte gráfica con la que interactúa el usuario para escoger los parámetros de búsqueda. Además es en esta clase donde se crea la consulta con los parámetros que acaba de introducir el usuario y se invoca al servicio que la transmite a las APIJAVA. La última función es también un editor que en este caso se encarga de la apariencia gráfica del resultado. En ella se utilizan dos clases adicionales, la primera permite exportar la tabla de resultados a varios formatos, PDF por ejemplo. Esta clase se hace en XML aunque hay una interfaz en Eclipse que permite crearla manualmente. La segunda se encarga de la definición de las columnas de la tabla de resultados y de rellenar cada una de las celdas con el resultado adecuado. Una vez que se han creado estas clases hay que juntarlas mediante extensiones para que sean visibles en la plataforma. Para ello existe un plug-in que permite la definición de las extensiones, también se puede hacer escribiéndolo directamente usando XML lo que en ocasiones resulta más sencillo. En un primer tiempo se especifican las clases encargadas de la apertura y de la edición de la ventana de parámetros y de resultados de la función. A continuación se especifica en qué condiciones se quiere que la función sea visible y esté disponible. En este caso se desea que la función sea visible cuando nos encontremos en la categoría Async Monitor y cuando la subcategoría seleccionada sea la tarea. La función debe estar disponible cuando una de las categorías esté seleccionada. Estas son las principales clases que se han tenido que crear, no obstante también se han escrito ciertas clases necesarias para el funcionamiento de cualquier funcionalidad pero que no tienen especial interés puesto que se trata de clases cortas y genéricas. Llegados a este punto la función Display está terminada y operativa siguiendo las especificación iniciales y se puede empezar la programación de la función Monitor. A pesar de tener que crear todos los archivos para esta función, incluido el servidor, su desarrollo es muy similar al de la función Display, puesto que realiza las consultas a las mismas tablas de la base de datos. Tanto en el servidor como en la parte cliente se han creado los mismos archivos y clases y se ha seguido el mismo procedimiento.

Una vez que se ha concluido el desarrollo de la función Monitor y por ende el del proyecto tal y como se imaginó en un principio, se añaden ciertas mejoras orientadas a facilitar la búsqueda de información por parte del equipo de soporte. En el caso de la búsqueda de servidores y de subtareas se añaden ciertos campos en la ventana de parámetros. En el caso de las tareas lo que se añade es una vista en detalle disponible en la ventana de resultados. Se abre al hacer doble clic sobre cualquiera de las tareas y en ella se despliegan las subtareas en las que se divide la tarea seleccionada. A continuación se muestra el resultado final, incluyendo las mejoras, para el caso de una búsqueda de tareas, en ella el usuario ha introducido una fecha cualquiera: Figura 2: Ventana de parámetros de la función Display Figura 3: Resultado con vista en detalle de la para una tarea búsqueda de una tarea Con la aparición de las nuevas tecnologías nos hemos acostumbrado a recibir la información de forma instantánea, vivimos en la era de la inmediatez. Este concepto se aplica a todos los aspectos de la vida, tanto en el mundo laboral como en el día a día. Ser capaces de ofrecer un servicio de forma rápida y eficaz se ha convertido por lo tanto en un desafío fundamental que todas las empresas deben afrontar. Es aún más cierto en el mercado financiero y en particular en un servicio de ejecución de órdenes en tiempo real. Esta es la idea principal en la que se basa este proyecto, que busca dotar a la empresa de una herramienta que le permita ser más rápida, eficaz y reactiva. Una vez se ha concluido el proyecto se puede afirmar que el objetivo se ha cumplido. Gracias a las dos funciones que se han realizado se puede proporcionar al cliente una respuesta mucho más rápida sobre porque ha fallado su operación y a raíz de esto ofrecerle una solución en un plazo más corto. También permite llevar un seguimiento más preciso del estado de los servidores para poder corregir los fallos con mayor brevedad incluso antes de que el cliente tenga que contactar con la empresa, de forma que cuando lo haga ya se le pueda proporcionar una solución de forma inmediata. De este modo se le ofrece al cliente un servicio de mayor calidad, lo más rápido y eficaz posible.

DEVELOPMENT OF A NEW FUNCTIONALITY INTEGRATED IN THE PATIO PRO APPLICATION OF 4TPM

Author: Nadal, Jean. Director: Thierry, Eric. Collaborating Institution: 4TPM

PROJECT SUMMARY

The securities department is a service offered by banks and other financial institutions that is responsible for the management of all transactions related to the trading of a financial asset. This is a constantly changing environment, particularly due to the increased use of information technology. This transformation is also characterized by the appearance of new sophisticated financial instruments and new services offered by this department, which requires an increasingly important use of computer tools.

Due to this digitization and increasing complexity, the financial sector is demanding more and more engineers and requires its employees to have programming and IT skills in general to understand its strategies and programs. It is therefore common to meet a large number of engineers who work in different jobs in the financial sector.

This environment includes this end-of-degree project, born from a 5-month internship at 4TPM, a French software company for trading and portfolio management. They are the developers of the PATIO platform used by banks and portfolio management companies and the project is carried out in their development team.

One of the functionalities that allows PATIO to its users is that of executing market bloc orders. This allows a manager to execute a single order in which several actions are performed for several of its clients. This type of order generates a complex task that PATIO handles asynchronously. The tasks arrive at some servers that, depending on their complexity, will divide them, or not, into a variable number of subtasks that they will assign later to other servers to execute them. This is a complex process which makes it difficult, in the event of a problem, to know when and on what server the failure occurred.

Until now, when a client has a problem, the support team manually searches for the time and server it has occurred. For that they have to search in the so-called logs of asynchronous tasks. Logs are files that contain the log of all the events of a process. This allows you to analyze step by step the internal activity of the process as well as its interactions with its environment. Due to its complexity, this search is time-consuming and not always possible, particularly when servers are located in the client's offices and there is no direct access to the logs.

Today, companies seek to increase their effectiveness by, for example, increasing the agility and speed of their internal processes and the services they offer. One way to increase this effectiveness is by computerizing processes that were previously done by hand. This allows for a considerable reduction in time due to the immense computing power of computers today.

The main motivation for carrying out this project is therefore to automate an internal process that is long, tedious and not always possible. This will allow you to reduce the process of searching for the logs to zero and make it immediate. This way you can quickly find the fault and solve the customer's problem, which is, after all, the most important thing in this type of situation.

The structure of the project is client-server and is divided into two different functions present on both sides. The first function, Display, allows you to obtain all the information related to tasks, subtasks and asynchronous servers. The Monitor function is used to immediately view the status of servers as well as tasks and subtasks.

Below is a diagram showing the relationship between the different parts that make up the PATIO platform, their connections with the environment and the parts in which the project is integrated.

Figure 1: Architecture of the PATIO platform

The BACKEND part represents the server part in which certain C files have been added and modified to perform SQL queries to the server tables, tasks and subtasks.

On the other hand, the FRONTEND part is the client part where an important number of classes have been added. This is due to the fact that in this part it has been necessary to create the whole structure as it is, in the context of this project, the first time that data related to servers, tasks or asynchronous sub-tasks have been manipulated in the company's web services. This part, written in JAVA, allows the creation of the interface with which the user can make the queries he wishes, as well as the communication with the server.

The project began with the development of the Display function, which, being more complicated and complete, allows us to understand from the outset how the communication of the company's client-server structure works.

First of all, the server part is developed, in charge of creating the query to the database with the information received from the client. This part is written in C language and following a bottom-up approach, i.e. starting at the bottom, in this case the database, and finally reaching the communication with the customer. Certain functions and structures need to be added to existing files that manage actions related to tasks, async_task.c, subtasks, async_subtask.c, servers, async_registration.c and their respective header files. In each case the modifications are very similar and are aimed at adding the option of making queries to its table in the respective database.

In the header files a structure is added in order to store the information coming from the client and create the query based on this information. This structure defines the same variables as the table to which the query will be made, so that queries can be made by filtering with any variable of the table.

In the .c files a type of structure is first added that will allow the coding of the variables defined above, when sending the information to the client, and the decoding of this information when it is received. This procedure already existed and is performed on all files on the company's server. The following 3 functions are then added to each of the files. In the first one, depending on the type of query, which in our case is read type, it associates the mess_tag code and the ID of the table and makes the call to the second function. This function is responsible for identifying the type of query and calling the function responsible for carrying out the action. In this case they are read queries so the third function, is called. This is the most important function since it is where the client's query is analyzed, the SQL query is created to the database, the result of the query is sent, stored and finally the information requested is sent back to the client.

Below is the SQL query that is created if the information received from the client is the status and date of creation of an asynchronous task:

SELECT * FROM ASYNC_TASK WHERE DTCREAL = "date of creation" AND STATUSI = "status"

This is the general dynamic on which the server is based for this function, however there are certain differences particularly in the server_read function and in the way the SQL queries are created between the async_task, async_subtask and async_registration files. This is simply because the information contained in their respective tables is different.

Once the server is done you can start the client part. For this part it has been necessary to create new files. This is because until now, there was no transit of information about servers, tasks or subtasks between the server and web services so it is necessary to create the entire structure on the client side.

The first thing to create are the APIJAVAs, which are responsible for communication with the server. It requires the creation of 6 classes, one for each type of data (server, task and subtask) and its respective class that manages the query. The first group defines the variables that make up its respective table. In the query classes, the variables with which you can filter are defined, in this case they are the same as those that make up the table so that they can potentially be filtered thanks to any of the variables in your table. In addition to this two functions are added, the first one will construct the query with the parameters entered by the user. The second function creates the socket that connects to the server, makes the call to the previous function, and receives the result from the server.

The upper layers without being more complex to program, require a very important number of classes. Because in many cases it is necessary to perform a class for each type of object, thus obtaining three very similar classes that perform the same action in the case of tasks, subtasks and servers. The usefulness of these classes is explained below, focusing only on those that deal with asynchronous tasks.

The first thing to do is to create an object in which the variables of the task table are defined, it is not mandatory that they have the same name as in the APIJAVA since it is necessary to create a class that acts as an adapter associating the content of the APIJAVA variables with that of the variables of this class. In this case, a type of query type is also created in which only the variables with which the user can filter his search are defined. In the case of tasks, the status, the user who created the task, the creation date and the start and end times have been chosen.

Next, a group of classes is created that allow the opening of the functionality in the platform, an editor for the parameters window and another for the results window. The first class is very basic and simply specifies the name of the editor and the function. The second one is one of the most important since you have to write the whole graphical part with which the user interacts to choose the search parameters. It is also in this class where the query is created with the parameters just entered by the user and the service is invoked to transmit it to the APIJAVA. The last function is also an editor that in this case is in charge of the graphic appearance of the result. Two additional classes are used, the first one allows exporting the results table to various formats, PDF for example. This class is done in XML although there is an interface in Eclipse that allows you to create it manually. The second is responsible for defining the columns of the results table and filling each of the cells with the appropriate result.

Once these classes have been created, they must be joined together using extensions to make them visible on the platform. To do this there is a plug-in that allows the definition of the extensions, you can also do it directly using XML which is sometimes easier. The first step is to specify the classes responsible for opening and editing the parameters and results window of the function. You then specify under which conditions you want the function to be visible and available. In this case you want the function to be visible when you are in the Async Monitor category and when the selected subcategory is the task. The function must be available when one of the categories is selected.

These are the main classes that have had to be created, however, certain classes have also been written that are necessary for the operation of any functionality but that are not of special interest since they are short and generic classes.

At this point the Display function is finished and operational following the initial specifications and you can start programming the Monitor function.

Despite having to create all the files for this function, including the server, its development is very similar to that of the Display function, since it queries the same tables in the database. The same files and classes have been created on the server as on the client side and the same procedure has been followed.

Once the development of the Monitor function has been completed, and therefore of the project as originally imagined, certain improvements are added to facilitate the support team's search for information. In the case of server and subtask searches, certain fields are added in the parameter window. In the case of tasks, what is added is a detail view available in the results window. It opens when you double-click on any of the tasks and displays the subtasks into which the selected task is divided.

Below is the final result, including the improvements, for the case of a task search, in which the user has entered any date:

Figure 2: Parameter window of the Display function Figure 3: Result with detailed view of the search for a task for a task

With the advent of new technologies we have become accustomed to receiving information instantly, we live in the era of immediacy. This concept applies to all aspects of life, both in the workplace and in everyday life.

Being able to offer a service quickly and efficiently has therefore become a fundamental challenge that all companies must face. This is even more true in the financial market and in particular in a real-time order execution service.

This is the main idea behind this project, which seeks to provide the company with a tool that allows it to be faster, more efficient and more reactive.

Once the project has been completed, it can be said that the objective has been achieved. Thanks to the two functions that have been performed, it is possible to provide the customer with a much faster response as to why his operation has failed and, as a result, to offer him a solution in a shorter period of time. It also allows for more accurate tracking of server status so that faults can be corrected more quickly even before the customer has to contact the company, so that when they do, a solution can be provided immediately. In this way, the customer is offered the highest quality service, as quickly and efficiently as possible.