Skip to main content

Hi community

In our application we use the tsf_translate function for the translation of messages in our business logic (see post 

 for details) .

However, we have some problems using the translated messages in unit tests. The function is depends on the session_variable ‘tsf_appl_lang_id’, but this is not set during the execution of the unit-test.

Setting the session_context for ‘tsf_appl_lang_id’ in the preparation of a unit-test is also not possible, resulting in an error ‘Cannot set key 'tsf_appl_lang_id' in the session context. The key has been set as read_only for this session.’ during the execution of the unit-test.

Any ideas how to test for messages generated by tsf_translate in a unit-test?

Your help would be appreciated.
 

Hey André,

Not sure if it works but maybe you can set the session variable in the Preparation query. Hope that helps!

e.g.:

EXEC  sys]..sp_set_session_context] @key = 'tsf_appl_lang_id'
,@value = 'ENG'
,@read_only = 1;

 


Hi Mark,

Thanks for the quick response, but this won't work. I still get the error for setting a read-only session context key
 

 


It might not be possible at the moment, we'll need to contact the Indicium team for that. I'll get back to you once I know more.


Thx Mark


Hey André,

I have contacted the Indicium team and the complexity lies in that this process in a System flow. As this is not a User process, the session variables are not given a value. 

Which tsf_appl_id would you have expected? Note that the pool user might not be an IAM user and thus not have an Application language. 


Hi Mark,

Reading your reply gives me an indication for solving this. Will running the system-flow as a known user in the IAM solve this problem?

I want to return tsf_appl_lang_id =’ENG’ as all our messages are in English and i want the tsf_translate procedure give me at least a value.

Another posibility could be adjusting the tsf_translate function and return the default (ENG) message when no tsf_appl_lang_id is available.


Adjusting the tsf_translate function to always have a fallback language is not a bad idea. In case the user uses "Italian” but the tsf_translate function cannot return that language, that the functional falls back to English.

The functioning of session variables will not be changed, so they'll stay read only.

We do see the potential of adding a user_id to the Application connector process action. For example, if you have Logging functions or procedures that logs the actions a user takes, you would like to be able to test that. Maybe admins always get logged, and regular users get logged less. With a User_id, that would then be feasible. In regards of session variables, these would then be filled with data from that given user.

This would require some work to be done to both the Software Factory and Indicium. Feel free to create this idea 😄

Would that suffice?


Hi Mark,

For now the adjustment in the tsf_translate function with a fallback language did the trick and helped me. This solution will help us for now.

Perhaps i will raise an idea for the application connector in the future