1 sql request per property, or only one "big" sql request ?

How are you planning on merging distinct requests? One case I've seen where you need something like this is when you want to get a valid subset of filter values (which would return 1+ rows) for each next filter, but in the end all filters are still combined into one query.

You need to decide on:

• what predicates are allowed (=, %STARTSWITH, <, >, LIKE, IN, ISNULL, BETWEEN)
• what logic operations are allowed (OR, AND, NOT)
• are nesting and brackets allowed
• is it free form (auto constructed from metadata) or fixed (from a pre-set list of properties).

After that on a client you construct filter object, validate and parse it on a server and execute the query.

If you're not satisfied with performance, server-side part can be tweaked without modifying the client.

what's the disadvantage of using lot of indexes ?

INSERTS/UPDATES are slower, more space is needed.

Tasks contain session reference so you can simplify your query to:

SELECT
TaskStatus_Request As ID
FROM EnsLib_Workflow.TaskResponse
WHERE TaskStatus_SessionId = ?

For debugging: add hang 1 before executing SQL. What happens?

What do you want to do with ID?

Great project, @Henrique.GonçalvesDias!

Sent you a small pr.

I have three questions:

1. Why CSP instead of REST? It doesn't seem too highload of an app, being an admin tool essentially, so I just wonder why you decided to go with CSP.
2. Let's move filtering to the server. Currently only the last 200 messages can be retrieved.
3. Are there any plans to add visual trace? Our default visual trace is great, but when a single session exceeds 300-500 thousands of messages it's not as responsive. So I've been searching for a enhanced tool for session viewing.

Check xmlStatus, it's an error:

ERROR #6237: Unexpected tag in XML input: RawMaterialThicknessUnit (ending at line 7 character 29).

You need to either specify all properties or define this parameter in both classes:

Parameter XMLIGNOREINVALIDTAG = 1;

Check this discussion.

General approach is - create bash fine with required commands and call it from Jenkins.

%File provides a way to get creation and modification dates, but to set them you'll need OS level tools.

Read method does read 32000 characters by default, you can specify an amount of characters up to $$$MaxStringLength (3 641 144 characters).

If you want to set property to a stream you can do it like this:

do objInArrMain.%Set("Content", fileStreamBase64, "stream")

I'm not sure when it became available, here's a simple check code:

set stream = ##class(%Stream.TmpCharacter).%New()
do stream.Write(123)
d obj.%Set("prop", stream, "stream")

It should output:  {"prop":"123"}

One other note: you're using file streams for temporary outputs (when building fileStreamBase64), replace file stream with temp stream for better performance.

Since ##class(%iFind.Utils).Highlight  and %iFind.Highlight  are the same method, you can pass fourth pTags argument to it:

SELECT %iFind.Highlight(Narrative,'"visibility [1-4] mile*" AND "temp* ? degrees"', , "<span>")

Another suggestion.

You can define a %ZSTOP routine which would automatically clear ^HITLIST global on job end.

You can also use PPG which would be automatically deleted when job ends.