Hi @Evgeny Shvarov,

I fully agree with the answer above from @Herman Slagman so I won't repeat what he wrote.

You asked me:

Which of them is not useful/silly?

As already reported in my previous post in February in other tread, many rules contains errors, I don't think I should repost the same comments, so please have a look to my previous post for details of some of the errors in the rules. Please note that the errors I comment/report is not a complete list of all errors in the rules, just some random I had time and will to report, there are more than that.

As for the not useful/silly rules I gave you two additional examples on top of what @Herman Slagman already wrote. Again, there are more than this few reported.

Class has too many properties
A long property list can indicate that a new structure should be created to wrap the numerous properties or that the class is doing too many things.
Maximum allowed number of properties (inclusive)
Default Value: 10

A class with more than 10 properties is considered a Quality issue? Really?
Most of complex real life projects have classes with more, sometime much more, than 10 properties, simply because real life "things" are complex and often have many possible attributes.
Just as an example, there are so many classes among IRIS "system" classes (part of the various frameworks) that have much more than 10 properties and this for very good and valid reasons.

Class has too many methods
This rule checks that a given class has a number of methods which is less than, or equal to, a configurable threshold. A class with too many methods is often an indication that this class needs to be refactored into several, smaller classes.
Maximum number of methods allowed for a class
Default Value: 10

Same as in number of properties. Useless to repeat.

So, ObjectScript Quality tool has many rules with errors and some rule is....well....debatable.

I fully agree on your statement "It’s difficult to introduce rules that will satisfy everyone" and that's the very reason why in my previous post in other thread I avoided mentioning "debatable" rules and only reported errors in the rules. Now you asked, so I had to comment on that too.

The issues (plain errors) reported in February has never been fixed/considered, that's why me and @Herman Slagman said that nothing has changed since February.
This gives the impression that nobody cares of the quality and maintenance of ObjectScript Quality Tool.

As for the invite to develop our rules I'm sorry but I don't have time, knowledge and will to do so, my contribution was to report errors and, if anybody cares (so far it doesn't seem so) to fix them, I can report more errors and "debatable" rules.

My concern in your endorsement of ObjectScript Quality tool is that some new IRIS user may think this rules are valid good practice and guidelines for coding in ObjectScript when, in fact, many rules are not at all.

I'm not sure if "no tool is better than a bad tool" as Herman wrote, but the risk of misleading people is very high, I think that at least a disclaimer and warning to people looking at it is advisable.

Hi @Herman Slagman, I totally agree with you, we have already discussed the issues and errors of "ObjectScript Quality Tool" rules in this post where I commented some of the errors in the ruses and there are indeed many more errors and, as you mentioned, some rule is debatable (or silly, as you said) to say the least.

Since that post and the errors I reported there nothing has changed, the rules are still there, wrong and unchanged.

What's the sense of having a "ObjectScript Quality Tool" with....such a poor quality itself?

To @Evgeny Shvarov, you say:

It’s difficult to introduce rules that will satisfy everyone.

Do you think that contradictory rules and rules with errors (plain errors) can satisfy anyone?!

what prevents you from introducing your own rules?

Time and probably I think it wouldn't be fun.

Let’s discuss....

We have started a discussion in the post linked above, I have reported some of the errors in the rules, nothing has been done/fixed. This gives the impression that "ObjectScript Quality Tool" is a dead project.
 

How about:

:clear

!del %USERPROFILE%\.iris_history

If/when you set KeepIntegrity to True, then ALL messages and message headers belonging to a session containing ANY message with status Created or Queued or Delivered or Suspended or Deferred are NOT deleted/purged, same goes for the headers (Ens.MessageHeader).

Since your is a test environment, it's (very?) likely having "messed" sessions that are not purged using KeepIntegrity  = True.
Sometimes even production systems do have sessions that are not purged using KeepIntegrity  = True.

While setting using KeepIntegrity  = True is "best practice" and prevent purging "uncompleted sessions", I suggest to run a purge with KeepIntegrity  = False with a (much?) longer DaysToKeep parameter, unless you do need/want to keep uncompleted sessions and messages for.....ever and ever.

For example, if you purge with KeepIntegrity  = True and DaysToKeep=30, you may run a second purge with KeepIntegrity  = false and DaysToKeep=90 (or longer) to purge really old messages belonging to "uncompleted" sessions.

When you purge that namespace with 30 day retention period, what value of "Purge only completed sessions" (was Keep Integrity in older versions) do you use?

Have you ever run the purge without including message bodies?

Code adapted with your details:

Set objHttpRequest = ##class(%Net.HttpRequest).%New()
Set objHttpRequest.ContentType = "application/fhir+json"
Set objHttpRequest.Server = "localhost"
Set objHttpRequest.Port = "52773"
Set pRequest = {"asd":"asd"}
Do objHttpRequest.EntityBody.Write(pRequest.%ToJSON())
If objHttpRequest.Send("POST", "/aktest/test") {
    Set objHttpResponse = objHttpRequest.HttpResponse
    If $IsObject(objHttpResponse.Data) {
        Set objStream = objHttpResponse.Data
        Set json = ""
        While ('objStream.AtEnd) {
            Set json = json _ objStream.ReadLine()
        }
    } Else {
        Set json = objHttpResponse.Data
    }
    Set httpStatus = objHttpResponse.StatusCode
    Write "Status: ", httpStatus, !
    Write "Response: ", json, !
}

This is the response from Ask Developer Community AI

You may try with:

set tQuery="{ CALL dbo.SavePatientDetails (?) }"

Set tParams=1
Set tParams(1)=xmlContent
Set tParams(1,"SqlType")=$$$SqlVarchar ; or 12 if macro does not resolve
Set tSC = ..Adapter.ExecuteProcedureParmArray(.tResultSnapshots, .tOutputParms, tQuery,,.tParams)

For details see the SQL adapters documentation on Using Parameters.
 

Does it works if you use NVARCHAR(8000)?

My guess is that IRIS does not understand "MAX", if so...maybe there is a possible solution.

P.S.: what version of IRIS?

the ExecuteUpdate method expects the parameters to be passed in as an array

Actually, no, it expects  parameters as single/literal values.

The method ExecuteUpdateParmArray() expects parameters to be passed in as an array

How did you converted the stream to base64?

Julian is correct, your code is inserting line breaks, remove the lines:

    If 'pInput.AtEnd {
        Set tSC = tStream.Write($C(10))
        $$$TRACE("Adding terminator.")
    }