Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

2004 Ideas

HarryACaptain

Improve the workflow for maintaining unit testsCompleted

Currently creating and maintain unit tests is extremely cumbersome, to illustrate I’ve written down the steps I needed to take to fix the unit test for a simple default.1.    Go to Unit Test2.    Run unit tests3.    Filter on Failed Unit test4.    Have a look at actual output5.    Open functionality6.    Try to find the code the unit tests is based on7.    Check the code8.    Go back to the unit tests and op the maintenance tab9.    Go back to Unit tests to copy the name of the failed unit tests since the failed unit test is not by default selected.10.   Check input parameters11.   Select tab expected output -> check output parameters12.   Check Mock Data to see which data set is coupled13.   Select tab Mock data set14.   Select data set that is coupled to the unit test (again I need to do this manualy since there is no reference)15.   Look for the tables that are used in the code16.   Go back to the tab with the input parameters to check how the code will interact with the mock data17.   Open the mock data to see the expected value18.   Fix the mock data.A big problem here is that the UI is failing me, I need to keep switching back and forth between tabs to look at the input/output parameters, mock data and actual code. Furthermore is switching between these tabs made difficult because there are no reference in place to open the detail I’m working on and need to keep looking for this.I don’t have a cut and dried solution for this problem but I do think this part of the SF could be improved by having a look at which information should be shown when (maybe an elaborate screen type of some sort) and reevaluating the workflow.  

Menu-based OpenAPI specs and metadataClosed

Our application is very large. This also leads to a very large OpenAPI spec (~50MB) and metadata file (~3MB).This is disproportionate for any external application that may wish to integrate with a Thinkwise application, which generally only need access to a small portion of the application.However, the OpenAPI spec is considered the industry standard for consuming an outward-facing API.In our Thinkwise application, we have several defined menu’s for different apps, which can be switched to in the Windows GUI through the context menu.See below screenshot for an example:The context menu within the Thinkwise Windows GUIThe “DMS app” and “Klantportaal” are menu’s containing a subset of views, tables and tasks which the respective applications use.Currently, these applications each required a lot of effort to implement each endpoint, because there is no tangible way of getting the specs for this menu.I understand, from this answer on a forum post, these specs and metadata files are filtered based on the authorized user's roles defined within the Thinkwise application.This is sufficient in the context of a user account defined in the platform, but falls short in the context of an external application which doesn't interact with Thinkwise in the context of a user.Currently, in Indicium Basic, the OpenAPI spec and metadata are available at http(s)://{{server_url}}/indicium/[iam/sf]/{{app_id}}/openapiandhttp(s)://{{server_url}}/indicium/[iam/sf]/{{app_id}}/$metadatarespectively.It would be a great addition for Indicium if these endpoints could become available per menu. For example, the OpenAPI spec for above “dms_new_mobile_app” menu could be accessible through http(s)://{{server_url}}/indicium/[iam/sf]/{{app_id}}/dms_new_mobile_app/openapior something similar.I think this would be a good step in making applications developed in Thinkwise more accessible to external applications.Currently, as a developer working on external systems, Thinkwise seems a very isolated environment, with little to no flexibility for integration.This seems like a design flaw for a low-code platform suitable for “large and complex business applications”, of which the data is almost always required by other applications that exist in an organizational landscape.I would love to discuss what possibilities there are, or even discuss other potential solutions for improved integrations.Should you have any questions, do please ask them in the comments.Thanks in advance!