That won't return accurate count unfortunately.

Consider a Text value like: ABCD ABC. It would be returned by iFind since ABC is in this text, however $Find would return 2 - incorrect number of ABC instances. More advanced iFind variants do additional text/term processing so I'd like to use it.

Additionally I know it's possible as there is highlight function so iFind can determine a number of search term occurrences in a string and highlight them, but I only need to return the number of occurrences.

I can highlight and count <b>,  but I wonder if a better solution exists.

Cubes rely heavily on bitmap indexes for them to run fast.

Primarily each fact in fact table must be accessible via bitmap index.

In the past Bitmap indices worked only with positive integers, but now there seems to be a %BID approach - a surrogate key essentially.

I think InterSystems BI should throw an error or generate a %BID or offer to generate a %BID if the fact class id is not a positive integer

What would be best practice for data type assigned to the "Password" property and securing that password against prying eyes, both just browsing the global as well as via SQL? 

Do not store passwords at all. If you need to check passwords hash and salt them - there are enough functions in $System.Encryption to get by. The only exception is when you need credentials to auth against some external system, in that case

  1. Encrypt login/pass.
  2. Store them in a separate encrypted-at-disk DB with separate resource.
  3. Write API to switch into this DB and get your credential, ideally this API returns authenticated object and not the password itself.
  4. Check that it fails for app user.
  5. Use Privileged Routine Application to allow your app access to a separate DB.

Also check Managed Key Encryption - from the docs:

Data-element encryption for applications, also known simply as data-element encryption — A programmatic interface that allows applications to include code for encrypting and decrypting individual data elements (such as particular class properties) as they are stored to and retrieved from disk.

___________

Better yet, how can I prevent a specific property from being projected to SQL?

The best approach is not to store password at all. Still, there are several options:

  • Access management - if the user does not have access to the password column/table he can't access it. InterSystems IRIS supports CLS.
  • Internal - hides property from docs.
  • Private - hides property from SELECT * explorers, but it can still be explicitly referenced by name
  • Custom datatype - redefine getter to return data only to verified callers, for example check Security.Datatype.Password datatype implementation which returns *** instead of actual password value in ODBC context.

It's a popular question:

Can anyone tell me your use case? I encounter XML and JSON fairly often in integrations but it's always some specific schema, as defined by XSD for XML and plaintext for JSON (OpenAPI spec sometimes). So for me it's always XML Object JSON (where Object can be zero or more transformations between objects of different classes). But what's the case for a generic XML JSON with no regards for a particular schema? Clearly it's a popular and valid use case, and I want to know more about it.

Great article!

This is the part that would be fantastic if it were a pip package, especially if only for Linux, as AWS Lambda functions execute on Linux boxen. At the time of this commit, the api is not available via pip, but we are resourceful and can roll our own.

You can install NativeAPI using pip:

pip install https://github.com/intersystems/quickstarts-python/raw/master/Solutions/nativeAPI_wheel/irisnative-1.0.0-cp34-abi3-linux_x86_64.whl

It depends. Essentially Interoperability Productions take care of:

  • Parallelization
  • Queues / Async
  • Error management, mitigation, and recovery
  • After-error investigation (Visual Trace / Audit)
  • Unified overview of integration flows

For each integration or part of an integration you need to decide if you need these features and usually you  do. In that case all you need to do is to develop one or more Business Hosts containing the business logic and as long as they conform to Interoperability Production structure you would automatically get all the above mentioned benefits.

You pay for the convenience with the overhead for messages and queues.

In the cases where some (most) of these conditions are true:

  • external system (whatever it is) is reliable - downtime is a scheduled rarity
  • external system does not throw errors much
  • response time is stable and in the sync realm
  • interaction with the system is one simple flow
  • integration is extremely highload

You can choose to interface more directly.

Furthermore it's not Interoperability/no Interoperability, but rather a scale of how much you expose as Interoperability Hosts. In your example maybe having only a BO is enough and you can forego the BP?