Video: Observability Made Simple: How OpenTelemetry Transforms Uniface Applications | Duration: 3620s | Summary: Observability Made Simple: How OpenTelemetry Transforms Uniface Applications | Chapters: Introduction to Observability (16.895s), Platform and Announcements (101.855s), Observability in UniFace (238.815s), Observability Pillars Explained (301.955s), OpenTelemetry Integration Process (616.36s), Configuration and Implementation (830.86s), Implementing OpenTelemetry Configuration (1039.95s), AI Developer Assistant (2518.84s), UniFace AI Assistant (2608.095s), Goldcast Platform Navigation (3339.405s), Conclusion and Farewell (3453.55s)
Transcript for "Observability Made Simple: How OpenTelemetry Transforms Uniface Applications": Good morning. Good afternoon. Can everyone hear me? Can you hear me? Oh, perfect. Alright. Well, thanks so much for joining us today for our observability made simple, how OpenTelemetry transforms UniFace applications. You know me by now. I'm Julie Hohman. And today, let's see. I've got Mike and Jason, and we ask also welcome Dongbo from our engineering team who's gonna help us with some q and a and any other questions you might have. I apologize that my screen is so dark. I'm not I'm gonna have to get a Ring camera, so sorry about that. But let's just go over real quickly what we're gonna go over today. So what is observability, and why should you use it? Jason's gonna give us some practical examples, in using observability, and then, Mike is also gonna give us a quick review on the AI developer assistant that we recently released. And then we'll we'll end our session with ask us anything. So, hopefully, no question is off, off limits, but we'll try to answer as many as we can. And if we cannot get to those today, we will reach back out to you. Alright. Just a couple of housekeeping items. We are muting the attendee lines. We're using a new newer platform called GoldCast, and so that will make sure that you're all muted. But we're still learning about this platform. I think we I think we've practiced enough. We we've got it down now. We are recording today, and we will send that link out after the session ends. You can use the q and a, which is next to the chat button. We're actually gonna turn the chat off, but we want you to use the q and a, and it's located next to the next to the chat up there on the, upper right. We will also have a, survey at the very end of the session, and we ask that you please take a minute or two to fill that out. It really helps us, plan for our next sessions, and we like love to get your feedback. And, also, you're able to select, your language for subtitles, and it shows here on the screen where to find that. So if you wanna go ahead and and take care of that, if anyone needs that. And, unfortunately, not all languages are available, but, most of the major, language demographics are available. Alright. I just have a couple of announcements too. I wanna make sure everyone has signed up for the UNIFASE forum. The link is up here on the screen. I think Greta's gonna add it to the chat before we disable that. But it's community.RocketSoftware.com, and then you're gonna choose the UNIFASE forum. And then make sure you subscribe. There's the a button in kind of middle of the page there. You wanna click the subscribe button. In that way, you're alerted every time we add something new. So we're gonna post all of the monthly newsletters there. We do technical blogs, release announcements. You can, you know, help troubleshoot problems you're having, peer to peer. You know, you can give each other advice, and then we'll also be, posting any upcoming events there as well. So I encourage you all to share this information with your coworkers as well. And with that, I'm going to turn it over to Michael Taylor. Hi, and welcome, everybody. So I think most of you probably know me by now. I'm Michael Taylor. I'm the product manager here at UniFace. And today, you know, I can talk I'm gonna be talking about observability in UniFace. So, yeah, we we've done a a whole bunch of work in allowing UniFace to be opened up to observability. So my job here to start with is to sort of set some scenes, to have a look about why we want to have the observability, give a bit of background into it. And then then I'm handing over to Jason to do the the difficult work of actually showing you what we've done. Personally, I I find all this pretty impressive. It's it's it's gone in there really well. And, you know, credit where credit's due, Dongbo has had a lot of the influence in in putting this into the product. So thank you, Dongbo, for the hard work on that. So first of we'll have a look at the business value of observability. Yeah. So what we what we need to achieve with observability is the ability to be able to see inside a running application, find out what's going on. And in order to be able to do this, there tends to be sort of three pillar pillars of information. So the first one is the logs. Yeah? So this is the kind of information that you would normally get out in your log files. So you set your IO print in your face, and you get that information out. So this is information about how the, you know, the coming from the application about, you know, messages about what how it's been running. Yeah. And the next one is tracing. So this is the ability to to see what has been running and then have have some information about that. Yeah? And the last one is metrics. So these tend to be cumulative information that that is output to observability platforms. So as far as UniFate's concerned, just to address this really early, we have been we have out we are now outputting both the metrics and the logging. Okay? But what what's this there to do for us? It's there to help us diagnose problems within applications and to be able to get the any system downs or any problems in the application fixed and up and running again as soon as possible. Yeah? And by doing by being able to do that, you know, we we are boosting how good the customer ex experience is when using our application. Yeah? But on top of that, we always strive to find out if we can make our applications better for users. So it's not just about diagnosing problems. It's seeing how the application is working so that we can find out if there is a better way of doing it or is there a way of being able to streamline it, be able to find out where the bottlenecks are within the application. And in order to be able to do that, you know, that's why we have to look inside of running applications. So, Julie, can we go forward? So if we look at unifying the current challenges which we have, okay, we put out, we can put out a whole lot of of information. Yeah? But we put it out into text files. And and when you start having to find the correct text file out of a lot of text files, Yeah? Being able to find which platform it is on, especially in distributed environments where, you know, you could have applications running across multiple servers. You know, being able to find where that problem actually was. And if we had turned on all the logging and, you know, being able to get all out all the information, two things happen. One is we quickly run out of disk space because we, you know, we flood the amount of information that's there. And the other thing that happens is we slow down the application for the users, giving a a reduced experience to them. Yeah? So we go through a process of someone calls us up. We they say there's been a problem with the the system. We have a look around. We try and find it. We can find it or we may won't not be able to find it. And if we can't find it, we turn on logging and wait for the problem to happen again. Hopefully, we get information out and, you know, then we go on and start putting extra information in, extra logging, extra messages which go out into the log files, try and figure out what's going on. Then we fix it and we can move on. Yeah? So it's, you know, it's not a great experience. It gives us all the information, but that experience can be really enhanced. Yeah? There's a lot of tools out there today which, you know, would give us a great deal of benefit. Okay, Julie? And again. So what does OpenTelemetry give us? And and OpenTelemetry is the the framework which we've integrated into UniFace. Right? So what we want to be able to do is output from UniFace into a standard format so that it can be collected by industry standard applications, and they can then display the information in a consumable way. Yeah? We have to you know, when we add this into the interface, yeah, we need to do it in a way that's easy for people to be able to adopt it. Yeah? So if you have to go through and rewrite your application in order to be able to get this information out, it's too big a task. So we have to be able to make it simple to be able to use and to be able to turn it on. Yeah? We can't have it so that it slows down the application. Right? So we we have to output it in a way that means that it can be constantly outputted output outputted output to the to the the systems so the information is there and available at your fingertips when you need it. You don't have to you know, you can turn it on permanently, and, you know, it's there for you when you need it. Yeah? And, you know, you need to be able to access it along with all the other logging and metrics which happen on internal systems. We quite often get requests from customers wanting to you know, they they are output they output information from their systems and from their databases and from their web servers, collected into, you know, in tools like Grafana or into Elasticsearch or whatever. And they wanna be able to get a similar kind of experience to the interface. Yeah? And with that as well, they wanna be able to get alerts. So if something is sensed as being wrong in the system, then they get alert. They've got all the information in order to be able to deal with it. K? So that's what we have to try and achieve while integrating OpenTelemetry into UniFace. Can we go to the next one? And the next one. Okay. So what what did we do in order to be able to get this into UniFace? So first of all, what we've done is we've integrated it at a low level into the UniFace runtime. Yeah. So it's not something that needs to be put embedded within the you you know, your source code. This is something that is information gathered from the running interface application, from the runtime. Yeah? We have implemented it in such a way that all the information is passed off into a separate thread in order to be able to keep the application running at a at a fast rate. Yeah? So the the challenges which which we mentioned before where turn logging on would slow down the application. Yeah? This we we have overcome them generally with our log files, but also that greatly helps here where an application can always be outputting information into a log server, and then, you know, it is there and can be tested and can give alerts when something goes wrong. And and developers can then start looking at these logs, finding out how their system is performing, and and, acting on challenges or looking for opportunities to improve. With OpenTelemetry, you are able to send it a standard format, which is what we do. And then OpenTelemetry in a in an area of it called a collector can then distribute these logs and traces to multiple different systems. So just through configuration within the collector, you can enable Grafana or Elasticsearch or or any number of other tools which are out there. It is also possible to be able to send it to multiple of them. So if you have some people who are wanting to see it in Elastic and other people wanna see it in Grafana for some reason, then that's also possible to do. So we have a single point we can send it to, and that can then distribute it to to multiple different different back ends. Yeah? And it really does open up the application. You know, you can see all the calls being made. You can see the proc code that's being executed. You can see the timings of everything. You can drill down to see the logs which are which are bound to the the particular module PROC modules which are running in UniFace. So it really does give you a a clear overview of what happens. And on top of that, you could also preprocess everything that goes through. So you can also, through this preprocessing side of things, do things like sampling where it is sent to to the the the the the the collector, and then the collector can say, well, actually, you know, I'm I'm interested in performance, so I'm only gonna collect one in 10 logs that go through. So I can I can get a clearer overview with, you know, and and reduce the amount of information unless a a problem happens in my application? So there's a lot of configuration that can happen within OpenTelemetry that gives a great deal of benefit while trying to find out what's happening in the application. Okay, Julie? Okay. So we always look for calls to action. I would recommend that people try it out. I think Jason going to take you through what's, you know, a number of the configurations. However, it is enabled as a base feature within the UniFace runtime environment. So in your testing environments or in your development environment, you can turn it on. And the visualization stacks are available in things like Docker or some of the other containerized environments. So you can start seeing that information really soon. It can help you in development, and you can decide, you know, how how best that you would you would want to to sort of roll it out into live. I think this functionality grid, I think it should be used. So, yeah, I'm gonna say when you decide how you can decide how you're going to to roll it out into live. We are working at the moment on elearning resources so that we will get you know, so there'll be more information coming out about it. The configuration itself is is pretty simple. You know, where the creativity comes in is with these these other tools like Elastic and Grafana and and and the other ones. Yeah. So the whole point about observability is to become more proactive in being able to deal with issues, right? So look at how you can sense your application and make sure that it's up and running, and allow it to be able to to give you alerts when things are going wrong and give you the information about why it's gone wrong. Okay? And as we as we go through, you know, if anybody needs to reach out to us, would like to reach out to us, to talk to us about it, you know, we're here for you. And we'll go through technical enablement sessions. You know, in the end, the integration is is pretty is pretty simple. There's not much needed within UniFace to configure it and to turn it on, and it gives you, you know, quite a lot of granularity within there. Right? But, yeah, we're happy to help and to get involved with you. Okay? Next. So now this is where I turn around to Jason. I've said a lot of stuff. This is where Jason, proves me right. K. Thanks, Mike. Screen. So yeah. As Mike probably said fifteen, sixteen times, setting this up is actually very straightforward, and I will show you that now. Let me share my screen. Okay. So I have a few different examples. When we talk about observability, it applies to things like the uniface run time, the u server, u router, but also other technologies. So we use Tomcat. So I've also set it up against Tomcat. We will just look at the UniFace setup for now. And what it is really straightforward. This is, I hash include my files while I'm setting things up. So what we can see is we have a new section called observability. Oops. Make that bigger. This one is done. Yeah. So we have a new section called observability, and it really is this straightforward. You say trace equals on if you want prop tracing. Depending on your application, your security, your environment, you wouldn't necessarily want to put tracing on in, live because, it exposes your source code, so your IP. So this would be during development or during, testing or fault finding. Logging, says, yep. I want to send my logs. And then we have the endpoints. Where do I send my, traces and where do I send my logs? That is it. So when we say it's simple to set up, it is. There are some other parameters that it makes sense to set. So service name, you can give it a name, and it's helpful filtering and allows you to identify. So for my desktop app, I've called it, desktop. For my server. So for my web application server, I've called it server. For my new router, I've called it UniFresh router so that I can easily identify it. Now, something you can see I've done in the u router is I haven't turned tracing on because, we don't have, top code running in the u router. So it's only logging turned on in that. Some of the other optional parameters you see in here then are, the span attributes. Easy way to think of a span is a module in unit place. So, an operation, a function, an entry, and so on. And what we can say to add to each span record is the status, the clock error, top profiling, and and tracing. Again, speaks for itself. The last parameters, depending on your environment, this is all just to help with the performance. So, as you know, when processing large amounts of data, you don't necessarily want to do one request for every single thing. So if you've got something with 5,000 lines, you don't wanna send 5,000 individual requests. So as we've always done in the past, we do batch processing on things. And ultimately, these parameters just allow you to control, the batch. So if you've a low latency network, you might want those batches to be, higher. If you've got a high throughput application and a high speed network, then you can afford for the batch to be smaller. But let's say, the core configuration you need to set up is, the bits at the top. Now Michael said, it's easy to test and we should play in the sandbox and, have a go. And you might be thinking, what what's this open telemetry collector? What's all this other craziness I've got to set up? It's actually really straightforward if you want to do some sandbox testing and explore on your own. Let me just move this for a second. So this is documented in the unipaste, documentation. And this isn't an an endorsement for any particular technology, but in terms of you being able to sandbox and play and start getting used to it, Docker, hotel, LGTM is a nice thing that includes a stack of stuff you need for OpenTelemetry. So, it includes Grafana for the visualization. It includes the OpenTelemetry Collector, which receives the information from UniFace and other products. I'm not quite sure how to help you with that. Great. Alexa's talking. It's not it'd be quite and then, yeah, within here, there's different tools for the different types of, things that are collected. So you have metrics. So I don't know. What's the memory usage on the server? You have the traces. So, the prop script, for example. And then you have Loki here, which, stores your logs. Now a thing to note, I don't know if Michael said this, is from UniFace at the moment, we are only recording traces and the logs. And if you remember from the, configuration I showed, you only turn trace or log on. We don't actually store any metrics at the moment, and this is where we'll reach out to you as you start playing with this. If you see this particular metrics, that you would be interested in, maybe some of the new router information like the number of requests or things like that, let us know. We haven't included anything so far because for a number of types of metric you would normally want to see about how things are performing, well, you get that anyway from the underlying telemetry of the operating system. So memory use, number of threads, number of mutexes, and and so on. So we haven't added anything from uni face. But I say, when you play with this, if you see something, let us know. So what you saw in the configuration was we specified an endpoint and that endpoint was to this collector. What I'll do is I'll show you this running now and then we will come back to the collector in a moment. So I'm gonna talk about, processing in there. So what I have is, I have a docker composed file for starting the for starting, the OpenTelemetry back end. And what that looks like is if you know Docker, this will be very recognizable to you. But ultimately, I'm defining a service called Grafana. The image is the one we've specified there. I give it a name. If for what exam any reason it crashes, I say just restart it unless I explicitly stop it. And here's where I'm exposing the port. It's listening on the volume mounts here just so I can persist the data. Because as you know, when you shut down a Docker container, it disappears forever. When you recreate it, naturally, you'll want to have your data. So I'm just my volume mounting to my local disk. So that's all it is in terms of configuring it. And again, we have examples of that. And when you go to this page, for Docker, it has the example. So let's get it up and running. Docker compose. That's not a store compose. Compose up minus d. So this will start my open telemetry back end. What you might find is in your organizations, you already have this. So you just need to speak to your DevOps people or IT administrators and ask for the, what the endpoints are. I go into Repana. You can see it shows yeah. It shows various things. Now I'm not gonna go into any depth about this tool because this is Grafana. It's one of the visualization tools, and it has tutorials when you first go into it. So what we can see if we go in here, we can see there's metrics. This is all coming from Tomcat. We have logs. We don't see anything at the moment because it's set to last fifteen minutes. We have traces. There's also nothing in there. So if I go to my UniFace page now, so I could do two things, actually. I'll start with where's it going? I have a desktop application here. I'll just get it to do some stuff. Load a file into it. K. It doesn't matter what this app's doing. It's just to so I just wanted to do some stuff. I could click around the app. So just imagine I'm working with any normal UniPace app. I finish it. I'm not had to make any changes to the code of the application at all. But if I now go into Refana and refresh, there we can see my UniPace desktop app, and we can see the logs it's recorded. We can see, the traces. We can see some metric well, some information about things there, how many spans per second, and so on. I'll come back to that in a sec. Go back to the web application, and try and log in. Admin. Super secure. I can go into my application. I can go around my application. I can do things. Go through tabs. Users. I connect permissions. I connect roles. Again, it's just a normal web application, and, I can just play and do stuff. Alright. Just come out of that. Now go back to Webfana. Okay. Logs, and I refresh that. We can now see I've got my logs from the web application. So you can already immediately see, doesn't matter what you've got in your estate, it can all come into this one consolidated, platform. If I look at traces, we can see a bit more in there. So there's the webshop that I'm running. Here's some information about Tomcat and, the new face desktop application that was there already. Let's drill into a trace. So if we go into the webshop and we can see the trace here, we can see various bits of my code. So tab quick view, something that's happening in that application. We can see things that are happening in Tomcat. Activate users HTTP w I r d exec when it's running the code. If I carry on down, we can see, container profile views. That's one of the screens. Let me click on that. And again, we're here. We're starting to see what was happening. So all of the top level, or spans, so the modules, the local prox, the functions, and things that were executed. Because I've got tracing turned on, let's go to no change, for example. If I click that, again, we see more information. We can see that I asked it to return clock error status. So we can see I had a clock error of zero, a status of four. We've got information about, the, component, the elapsed times, things like that. And here, events. So within that span, so within that, module, each line of prop code is an event. So if I click on that, and we can see the prop code is running. So at this point, nothing's really going wrong, so there's nothing to debug. What I just noticed as I scroll down, oh, I've got an error here. So profile data gets sourced from this. Something went wrong. Let me expand that. I can see I've got status of minus four. Let's drill into that and see what it was. So probably in here, it's where I've done a retrieve, like a get record where there was, nothing to actually get and that potentially, returned, the minus four. I remember. It's minus four table does not exist. But I'll be immediately, I can see that something's going wrong there. Let me go for some other examples. If I go into this, I'm gonna try, submitting this page without actually entering a username or password. Now this is going slow. Okay. Took a little while to come back. Let's see what Grafana tells me about that. So if I come in, let's look at the traces. So I can see webshop here. That felt like about three seconds. I can see, yeah, there's a slow one here. I can actually sort by dates, by times here to get the slowest and drill down on those. Let's see what this is doing. Okay. So come in here. So here, we can see that that took the three seconds, but this child took three seconds, another child. At the bottom level, this took three seconds just to tell me let's see what the events are. Okay. So there it is. Obviously, I've constructed this. I've got a sleep of two seconds. I've got a sleep of one second, so a total sleep of three seconds. But it's really quick and easy for me to find out where that, challenge was. Now we can always do things, so we can add events and alerts in here to help, get to things really quickly. And you can build dashboards to also show things. Now I mentioned the OpenTelemetry Collector. Now a thing to bear in mind is something we don't do is try to predetermine what the status is of your applications mean because we have no right to. That's something that you can control and, extend within what's called the processing of the OpenTelemetry connectors. So I'll show you an example of that. You can see it's actually already implemented on this one. So to get attribute, it knew that that was an error, whereas it didn't know that there's any problems with this logging. And if I were to look at the logs, for example, I've got an info message here saying warning, something is going far too slow. And that was the message you saw in my, constructed example. Now if this was a real warning or a real error or even if I scroll down, we could see things, maybe not now, but sometimes when you first start up UniFace and it's looking for signatures that aren't necessarily there, you'll get a file not found. Actually, you can see one down here. File system error, The system cannot find the file specified. Now in normal terms, I might just completely miss that because I'm not looking for it. There's nothing highlighting it to me. So what I'm gonna do is implement some additional processing instructions to handle things. And and actually, another thing to say here is this message, where I've done warn something is, going far too slow, that's just a put mess. And as you know, unlike something like message flash info, message flash error, and so on, put mess doesn't actually have a modifier to say what type of error it is. So one of my standards has been to always just put some text at the start. Say, well, this is a warning put mess or this is but that's just my standard. You will have your own standards and you can actually then utilize those standards to do things. So let me just show you what I'm talking about. So as part of that docker image, you can see I've got this, volume mount to a configuration file, and that's a configuration file I have locally outside of the docker image. Here's a copy of it. Most of this is just boilerplate, but the bit that's, special is the processes. And what this basically says is for every line that comes in, I'd like to apply, a process. Let me just make this full screen so it's a bit more readable. Let's shrink that down a little bit. So what you can see is, it's split into two distinct areas here. I've got my mouse is not showing up to the end. I've got my trace statements. So that's the clock tracing and the lines of code. And what you can see here is what I've got is to on the span itself, I'm saying set the status code on the span to status error if the attribute passed from UniBase called dollar status is less than naught. So I'm saying a negative status, I'm treating as an error. Therefore, set the status code to, error. I'm also just setting a status message on the span, which you will see, in Grafana. So I'm just saying or any other tool, actually. But I'm just saying the span has been marked as an error due to a negative, proc error. What we didn't see was anything happening to my, my put miss items because it's just my standard. But what I've got here is a similar thing, and I'll uncomment these now. So what I'm saying here is for each log message that comes through and has been put into the span, set the severity number. And in the case of this if I call it an info message, I'm gonna set it to info where the body of that log message starts with info. And then I'm just setting a text to say it's info. Set severity warning. I guess you're spotting the pattern here. On this last one, I'm saying, I'm also gonna treat a file system error as an error as well. So I put those in. Now there are other, options options you you can can set set which which may be, useful for your applications. So let me just bring that up for your reference. So I'm using okay. I'm using info warning and error, but you also have debug and trace. Fatal could be an interesting one because if we have an unhandled exception that bubbles all the way to the top and the application's gonna exit, pay tool's probably a good one to put in that final, try catch block. So, yep, there's been a pay to lower. The application has crashed. Okay. So I'll enable these, and you'll now see the difference. So I'll save that. And what I need to do is just restart the Docker container so it picks up a new, configuration. So Docker Compose down. It might take about twelve seconds. And then bring it back up. And then we should see some distinct differences this time. So, don't need that. Don't need that. So what I'll do now is I'll go back to this page. I can log in normally. All is fine. But I'll now go through a couple of, problems. So that first one was where I had that slow, piece of code. So same thing happens. I've constructed another issue where I just type in garbage in both fields. It's gonna try well, you'll see what it tries to do, but I get a runtime error. Let's go back to Grafana now and see what's going on. So if I refresh well, now you can see it's I put those processing instructions in processing instructions in there, it's telling me more of what's going on. So here we can see the file system error. It can't find the file specified, and I could drill into that to find out what, the issue is. And that's at the log level. I'm gonna go into the traces here. And where go into this one. What we should see We're gonna see it on the look files. And I come into the area that was faulty before. We've got the sleeps that we can see. We can see where I've done that message. What I didn't highlight to you before is what makes this super powerful is I've got to the area where there is a problem. I can see, yeah, I know there's this code or there's an error that's been highlighted, but what's in the log files? Well, I can say logs for this span. And here, we can see the message warn, something is going, too slow. So whenever whatever went wrong, and naturally, I just forced to put this out there, if it was a a proper database error or something that Uniphace has logged, you don't have to scroll through trying to find where that item is in the log to see what's going wrong. And what's more powerful is when you're then talking about something that's distributed across lots of different servers, for example, again, you don't have to start trying to figure out where in each log file the different things correlate because it takes you straight to the information. Then, I mean, that's basically how it works. It's really easy to turn on. You get lots of information, and the different tools, whether it's Grafana or Elasticsearch, give you different ways of drilling through the information and visualizing it. And another thing I can do is a simple dashboard I put together is I can just see things like the response times. I just got a list of all errors that have occurred. So that's in the last twelve hours. By saying the last five minutes, I can see, well, there's one error that's occurred. Couldn't operate that operation that doesn't exist. So now I know where to go. And I can see, oh, from a security perspective, I did put a warning in to say there was a failed login attempt and also capturing it is going too slow. And from here, if I double click no. Actually, not on this one. But in other places, you can always, navigate through and there she's there. Show log details. I get more detail here, and I can then navigate through to the, traces and other things. That's, it in a nutshell. I'd say depending on the tool, you have things where you can set up rules. So you can say the source is low key, so it's from my logs or Prometheus, or it could be, tempo for the traces and whatever. You can basically build queries and things to say, if I hit this condition, I e, if I see 500 failed login attempts in a one minute period, that feels like someone's trying to hack, you can then take action. If you see lots of database errors, you get a notification by email, you can take action. But say all of that functionality is what the tooling provides. UniPace now plays in that ecosystem and is really easy to set up. As we say, the base setup is trace on, log on, and where's my Grafana server. With that, I'd like to hand back to Michael. Hi. Sorry. Just had to farm my way back on stage and learn how to unmute myself. I'm not very good at muting myself. So the I hope everybody has appreciated Jason's presentation. I think that this is a great addition to UniFace, and it really does help with being able to understand how that application is running. You know, these tools, which are now available in order to be able to visualize what the UniFace application is doing, is going to really help us to be able to to make sure that we're delivering the best applications we can to to the end users and make sure they continue to run. So I think personally, I think it's a great addition to UniFace, I hope you all agree. Please, we do have an ask me anything at the end, but please keep the comments coming in the chat and in the question and answers. And, you know, those who are are there will be be answering them as we go through. So the the second thing that we we released at pretty much the same time as OpenTelemetry is an AI powered knowledge system, which is there. It's called the UniFace AI developer assistant, and it allows us to be able to if you can move on one, please. Yeah. So what is it? It's as I say, it's a developer assistant. It's they're meant to be the experts in your pocket. You can ask it questions about UniFace, and it can give you sort of answers to it. So you can delve quite deeply into the product, find out lots of information, information that is scattered throughout many different sources being consolidated down into this one environment where you can ask questions in natural language and get a response. You know, this is about and it's being trained on UniFace so that it is very tailored to the UniFace environment. But you can get in there. You can ask your questions. The kind of questions we expect are, you know, at the bottom of this slide, which are things like how do I configure my interface to use a particular license type? Or, you know, asking questions about the language itself. So how do I use a particular command? And then sort of more high level concept kind of things as well. You know, what API do I need to implement to develop a uniface database driver? And it can start leading you through the the the process. And it you can draw you can drill down. You can ask follow-up questions on it, and it'll give you a whole bunch of information. So, you know, what we're trying to do is to to put this information at your fingertips. Save having to go searching through large part parts of documentation in order to be able to get the information. You know, our our our documentation is a very large set. And then, you know, to be able to to get that information much more easily is great. Okay, so fifteen minutes left. So, right, if we go to the next slide. So how do we get to the UniFace AI assistant? So first of all, it is open to UniFace enterprise customers. People who are on maintenance, you can get access to be able to create an account and to be able to use the AI developer assistant. In order to be able to do so, you need to have a support account on on the Rocket community, the RCC, so that you can are able to log calls. And then that is matched to the the username and password, you the the email and password, which is used to in order to be able to create your account on the AI developer assistance. Yeah. So it's a pretty easy thing to do. You know, you can request that that account if you're if you're in a a maintenance enabled customer, and then be able to create your AI dev assistant account onto the onto the the website. And as I say, that then gives you a lot of information available your fingertips to natural language questions from Uniphase. It can also do some coding. We are we are continually trying to improve it. I would encourage everybody to, you know, when you're using it, to give us feedback to allow us to understand what is good and what is bad. Let us be able to to enhance it as it grows over time. What we don't do is we don't use any information that you pass in in order to be able to train our models. So, you know, it is stored in part of the prompt history, but it is not you know, it's a personal thing, and it will not be shared outside of your own personal chat stream. So, you know, you know, we will you know, the the chat history is saved. It's saved on our servers, But as I say, we we don't then share it with anybody else. We don't use anything that's entered or or any responses to then, you know, supply to anybody else. So, you know, feel free you know, feel secure that we are not going to be misusing any of the data in there. Okay. So that's the AI dev assistant. We would really encourage you to try it, get used to It really you know, I've been quite surprised at some of the questions I've been able to ask and really quickly got information back from it. So, yeah, we really do look forward to getting your feedback on that. The okay. So from now on, we we've got an ask us anything. So really, it does mean ask us anything. You know, we there's it can be we prefer, you know, we continue to talk about AI, we talk about observability. But if you've other questions, feel free to pop them into the chat as well. Have we got any questions come through? There are a few. And I wanna give a shameless plug to the survey. As you leave today, please complete the survey. But, yeah, we've got a couple over here. Oh, quite a few. Where should the complete environment be installed? On the UniFace server or on the UniFace client workstations? Okay. So, actually, it tends to be in a something central to to everything. Yeah. As Jason was saying that this can take this can collect information. I'm assuming this is about observability. So, yeah, we would put it on a central server containing your Grafana stuff or other tools are available. And then everything just feeds into it. So that's why, you know, in the assignment file, you you point it to a web location and then share it. When I've been using it, because, you know, I I tend to just use it for myself, I have a Rancher container engine running. And then there's a Grafana complete Grafana stack, which is available from Docker Hub, which I just download and run. So I run that locally. So it depends on your your use case. If you've got a big data center, get it centrally, you know, make sure everybody can get to it. If you're trying to do your your local tests and you're only interested in your stuff, then do it locally. Alright. The next question was and I think this was when you were talking about observability. No. Are there licensing requirements to use this? It's base product. K. Someone asked where can we find documentation, on observability, and that was put in the q and a. But I'm gonna put it over in the chat. Or, Greta, if you could do that for me, I would appreciate it. Okay. Okay. So the licensing sorry. The where can we get it? Documentation. Oh, Dongbo added a link to it as well. So it's in the documentation. You can also ask AI. Alright. On a production environment and situations where a customer has access to amend the assignment files themselves, is there any way to protect our code against them setting the trace option to on? For example, is that level of trace still available if a component is compiled with the node bug switch? We do not output any prop code if it is if it's no debug. Yeah. So you get all the other information. You get, you know, the spans which are being which are being executed. So you will see operation names and component names, but you won't see any of the code that is run within there. You will still also you are still also able to see the timing. So in the timings, you can see how long you spent in this module, how long it's spent executing, how long it's been idle, how long it's been waiting for a database, and how long it's been on waiting for a network. And there's also consolidated to show as well everything from It's it's and its children as well, so sort of summed up. But the the end the question about whether you can turn it off. Yeah. If you compile your application with no debug, we don't output. K. Someone asked what patch version it was released, and it's 10.40.3O3O. Yep. Okay. And then let me go back up. we have an enrollment, by the way. So it was released for Unix and Linux ten four zero three point o three o. You know, we we do have a design to release it as well for AIX and Solaris. It probably won't make it onto the I Series unless we have some strong questioning coming from customers. So if you've an I Series, let us know. I'm gonna put you on the spot or maybe Jason. Could you show an example of AI dev assistant? And it's okay if the answer is no today, but thought I would ask the question. Possibly. Okay. I'll give you a minute. I'll give y'all a minute, and we'll go to another question about that. Would it be possible that the AI agent can also help to get the correct number of parameters when calling an operation of another another service? Say that again, sorry. Would it be possible that the AI agent can also help to get the correct number of parameters when calling on calling an operation of another service? I think we list the parameters, but we don't list the datas within the parameters. Dongbo, can you can you get in on that? Uh-oh. What's the question? So, you see how many parameters are required for use on an operation, I think, is generally the question. No. Currently, don't support that. So we cannot see the parameters or the values or the parameters for the operation or any prod module. Yeah. But that's something, yeah, we can think about. Does that answer your question? I think so, yes. I think everybody can see the chat, so I probably won't reread those. Let me go back to the q and a. So I think we're we're just back to the could you show an example of the AI dev assistant, Michael? Yeah. Okay. So, I'm going to There's a Okay. I'll try and share my screen. I've not done this in the Gold Coast before. So you can share the screen, the app, or the window, I think. It'll show you on the right side when you go to share. I've lost my I just lost it. Sorry. Well, maybe we'll table that for now. This is a new platform for us, so we're all used to Webex and Teams, but Goldcast is new to us. So, I think I've got it. I think oh, think. I've screen. This one. Okay. There we seeing. there we go. Yep. And would someone like to put a question? That's really this is probably very foolish. So, one of the questions that we had in the presentation is what API do I need to apply to create a database And So, then you can start drilling down and asking subsequent questions for it. So, it's very much like you'd expect to see things like chat GPT, but the information is very much tailored towards the uni face environment. Alright. I think the rest of mostly are just comments that I see coming in. So we've got just a couple minutes left if you wanna, if you wanna go ahead and and ask any additional questions. But, thanks so much everyone for joining us, and we we plan to do several webinars throughout the year. So just keep an eye on the forum, which is where we're gonna post that information. I don't see any additional just do you guys see any additional questions that have come in? Oh, and Mike's gonna show us another. I think that was Dino asked. Oh, current data. I spelled it wrong. It's not gonna work. Current date. Yeah. Okay. Here you go. going into the JavaScript now. Okay. Alright. Well, I think we're almost at time. Thanks again, everyone, for joining us. Feel free to send in additional questions to the forum, or, we have uniface@rocketsoftware.com if you feel more comfortable, communicating that way. Or you know all of us, just reach out and send us an email. But, thanks to our speakers today. Thank you, Dongbo, for, coming on to help with q and a and and your technical expertise. And then thanks also to Greta for helping us on the backstage and to get prepared for this event. Everyone, have a great week, and talk soon. Thank you, everyone. That can do. All right. Bye bye.