EXEC dbo.tsf_send_message 'This is just a test', NULL, 0
end go
grant execute on "proc_startup" to public go
I still see different behavior for the Windows- and Universal GUI and Windows- and RDBMS authentication.
Windows GUI (2023.2.11) + Windows Authentication: No problems
Windows GUI (2023.2.11) + RDBMS Authentication: Stored procedure 'proc_startup' generated an error while deriving the parameters.
Information: Parameter 0 - model_id (model_id): An SqlParameter with ParameterName '@model_id' is not contained by this SqlParameterCollection. Parameter 1 - message (message): An SqlParameter with ParameterName '@message' is not contained by this SqlParameterCollection.
Universal GUI Nothing happens at all
Does the startup procedure need the parameters model_id and message?
Can you confirm that the startup procedure also works for the Universal GUI?
Hi Harm,
I'm not sure the StartupProcedure can have parameters, I didn't check that. But I also wouldn't know how values could be given to these parameters. Not sure why the login authentication type would cause different behavior. According to your description, we can classify this as a bug. Could you create a ticket in TCP? Linking this topic would most likely give enough information for a reproduction.
The extended property StartupProcedure is not available to the Universal GUI.
Mark,
Ok it is clear to me that using the StartupProcedure is not a good approach anymore, because it won't work for users that are using Universal or make use of the platform via Indicium.
According your response to the Question below, using a StartObject and start a task is a better approach.
The problem I see here is that proper function depends very much on an action to set the StartObject for users(groups) by the IAM administrator.
You're right about that Harm. Currently that indeed has to be configured in IAM itself. However, using Post synchronization code, you are able to set Start objects after synchronizing the model to IAM (or include it in the Deployment package). Using an insert query on table usr_grp_pref_start_object, you technically could add start objects to all tenants and user groups that have access to a particular IAM application. We also use this for the Software Factory. Example:
-- Add start object for all sf developers insert into usr_grp_pref_start_object ( tenant_id, usr_grp_id, model_id, branch_id, gui_appl_id, start_object_id, start_object_type, task_id, order_no, abs_order_no, insert_user, insert_date_time, update_user, update_date_time ) select 1, -- Default tenant 'sf_developers', g.model_id, g.branch_id, g.gui_appl_id, 'check_sf_upgrade_msg', 1, 'check_sf_upgrade_msg', 1, 1, system_user, sysdatetime(), system_user, sysdatetime() from gui_appl g where g.model_id = @model_id and g.branch_id = @branch_id and not exists (select 1 from usr_grp_pref_start_object p where p.tenant_id = 1 -- Default tenant and p.usr_grp_id = 'sf_developers' and p.model_id = g.model_id and p.branch_id = g.branch_id and p.gui_appl_id = g.gui_appl_id and p.start_object_id = 'check_sf_upgrade_msg')
You could argue that it would be more convenient for developers to be able to set Start objects inside the Software Factory in a way, and/or configure a StartupProcedure or ShutdownProcedure.
Feel free to create an Idea for this. I do feel that we could improve upon the StartupProcedure and implement a native way of allowing a Task/Procedure to run on startup (and on shutdown even)
Mark,
Thanks, your idea is clear to me and I will be able to make this.
Anyway, it will result in a much more complicated solution and mistakes can be made easily.
I will add an idea for a StartupProcedure and ShutdownProcedure that work also for Universal enviroments.