Hello @kage.wu,
dacsSubscribeClient is an example of OpenDACS implementation, it is a simple example that can be incorporated into your implementation, if it addresses your custom requirements, or you may need to do more.
This example uses checkSubscription API call, that requires itemName and not wild card, so one can not pass wild cards.
When designing entitlement handling in an application, we can not assume, as the responsibility for exchange compliance of the application resides with the designer, so every login has to be verified to be entitled, and every item access has to be verified to be entitled.
The alternative approach, to verifying every item access as subscription check "on the spot" against your DACS is a caching users entitlement, and upon item request, verifying the entitlement against the cached. Each item includes a dacslock with one or more PEs (Permission Entity) requirements The cache has to be kept up to date, as the entitlements can change.
To deepen the your understanding of what dacs locks are, it may be useful to review article The Use Case for Decoding DACS Locks and How To Do It. It may also be helpful to review An Introduction to the DACS Entitlement System for OpenDACS Developers, noting that IDN_SELECTFEED is most likely alias Elektron service (currently Refinitiv Real-Time), and is defined in DACS as content-based.
Hope this information helps