UC4Blog

Last week there was the UC4 user conference "Innovate EMEA 2013" in Munich.

If you are from the EMEA region, and you were not there, then you've really missed something!

At such a conference, you always learn many interesting things, and many of these, you learn in between the sessions. You think that the UC4-renaming-wave is over? They kept the best for the end. There hasn't been an official announcement at the Innovate conference, but there was lots of talk - in a few weeks, we'll all know more about it!

What has been officially announced in Munich is the new "UC4 DB Training": I'm developing a training together with UC4, that is for UC4 users with access to the UC4 database. It'll be available this fall in German - let me know if you're interested, but don't know German.

At the Innovate, I gave a presentation showing a few examples what you can achieve by using the UC4 database.

I'll post some or all of the examples at a later time.

Today, I want to introduce the DB-training to you, give you an idea, what it's about, and let you know all there is to know so far.

In many cases, the runtime of jobs or processes depends on the amount of processed data, the season, or other variables. Demographic reporting on China will probably run a lot longer than on Andorra, just like logistic processes of an online retailer will have more data in December than in July, or the overseas delivery of a power station generator will take longer than the delivery of small spare parts to the same address.

Many times, though, it is the same Workflow that processes small datasets on one occasion and finishes in minutes, and at other times is processes large datasets and takes hours or days.

For such Workflows, the Estimated Runtime (ERT) in UC4 is a bad measure to estimate the runtime or monitor the potential violation of SLAs, because the ERT is always calculated on the object level.

I will demonstrate an approach how you can parameterize your runtime estimations, and implement a dynamic runtime supervision based on this estimation.

One tip before I start: don't put too much work into setting up a full-featured, perfect automation of this concept for your environment, because I've heard that UC4 plans a feature for it in V10.

When I started to work with UC4, I started to collect handy SQL queries. Whenever I used a query to solve any specific task, I'd save the query together with a short description in my collection, so I wouldn't have to re-invent the wheel next time.

Today, I hardly use this documentation any more, I write most queries directly at the SQL prompt when I need them. One or the other of them might lead to a blog post, if it has some cool features or a good story around it, but usually I close the SQL client without saving after I'm done.

Today I want to share a few of my old collectibles with you - maybe you find something useful to you.

Attention: This blog post concerns MS SQL Server ant it's not all UC4 specific.

Some time ago I had to take care of a peculiar performance problem. The most obvious symptom were grayed out WPs  in System Overview, and the resulting loss of system performance.  Sometimes it could get so bad that the system was literally not responding anymore, but after some 10 to 20 minutes later, all symptoms vanished and within a few minutes, the system was back to normal as if nothing had happened.

The WPs' logs showed very long database queries, so that's where I started my investigation …

UC4 saves most object logs (called "Reports") in the database. There are a few exceptions, for example there is a size limit for Job reports, you can adapt it to your needs though. Inside the database, the reports are stored block-wise, the maximum block size is limited by the definition of the DB-field RT.RT_Content, where the report blocks are stored - 8000 bytes (technically this is not true for Oracle databases, but you cannot set REPORT_BLKSIZE greater than 8000, even if you use an Oracle database)

The report window in the UserInterface splits large reports into multiple pages, in the lower right corner of the window are the controls to navigate through the pages. A report can be split into very many pages, a SYNC object with a lot of activity can easily grow to 100 pages, especially since a page contains only 250 lines (messages) there.

Unfortunately, all menu items like "Print Preview", "Print" and "Export to file …" only refer to the current page of the report, not to the full report. The UserInterface currently provides no way to open or export the full report.
A few approaches to solve this: