Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1967 Ideas

kenterweemeThinkwiser

SF - Improved overview for assigning upgrade scripts to specific source model versionOpen

Story:As a SF developer I want it to be easier to assign upgrade scripts to my upgrade. The system should tell me what my source- and target model version is and display any available upgrade scripts for the timeframe I am in. Additionally, I want the system to suggest upgrade script assignments to me if there have been other script assignments with intermediate upgrades.Problem:When developing in branches and in DTAP environments, the Dev environment (nearly) always has a different release cycle than Test, Acc, and Prod. The Develop branch/environment receives way more intermediate upgrades before the model version is merged back to Release, or Main. With these intermediate upgrades sometimes upgrade scripts are required (usually for more advanced data migration).Currently, the SF allows the developers to add an upgrade script for all upcoming upgrades, or to one specific upgrade (from-model version X, to-model version Y). These data migration scripts are usually only required once, so adding to a specific version is the most logical thing to do, but this functionality is hidden very deep in the menu, requires multiple steps and screens and is therefore not user-friendly.However, when later upgrading the Test environment with the Release branch, you want the upgrade script to be run again. The problem is that this is a different upgrade (the from-model version is older, and the to-model version is newer) and thus the assignment of the data migration upgrade script is not accounted for, and skipped. This problem re-occurs with an even larger time gap when upgrading the Production environment using the Main branch.If not paying close attention to what is happening, or triple checking all from- and to-model versions and script assignments, the data can become a mess or even corrupt and the only way to solve that is by restoring a backup of your database after the upgrade has failed.Possible solution:Add an additional detail tab to the data migration screen, that shows all assigned upgrade scripts to intermediate model versions, and allows the user to include, exclude, or modify the upgrade scripts (or deeplink to functionality to edit). So that it is clear what scripts are included in your currently generated application upgrade. This creates a much more user-friendly way in managing your upgrade scripts and prevents accidental (un)assignments that can have unwanted consequences.  

Michael
Thinkwiser
MichaelThinkwiser

Model custom API endpointsOpen

To simplify the creation of custom endpoints in the software factory, I have the following idea:Imagine how convenient it would be to model endpoints easily.For example, suppose you want to provide an interface to your CRM application for third-party tools. To achieve this, you need a way to view and manage certain entities like relationships and customers within the system.Let’s consider a /customer endpoint where we can perform a few operations:GET → Retrieve a list of customers, with an option to pass a customer_id as a query string. PUT → Add a new customer. DELETE → Remove a customer. UPDATE → Modify a customer's details.The GET operation would return a text in the body of the response with a 200 HTTP status code. For this, I propose creating a procedure that takes customer_id as a parameter. (Side note: I am aware that query strings are not type-casted. Therefore, if a customer_id is provided, the service layer should validate whether it can be cast to the appropriate data type, in this case, an integer.)GET ExampleHere is a pseudo-code example for the endpoint:create procedure dbo.api_get_customer( @qs_customer_id int -- QS stands for QueryString, explanation follows in the PUT section. ,@request_body nvarchar(max) ,@request_header nvarchar(max) ,@response_code int output ,@response_body nvarchar(max) output ,@response_header nvarchar(max) output)asbegin set @response_code = 200 set @response_body = 'Lorem Ipsum is simply dummy text of the printing'end  You can output the body in JSON, XML, or any preferred format.PUT ExampleFor PUT operations, it would be helpful to specify that the endpoint expects a multipart form, which can be interpreted as variables in the subroutine.To achieve this, you would define the parameters/fields expected in the form along with their data types. For example, we could expect a name as a varchar and logo_photo as a varbinary.create procedure dbo.api_put_customer( @mf_name varchar(255) -- Specified through the domain system in the software factory ,@mf_logo varbinary(max) ,@request_body nvarchar(max) ,@request_header nvarchar(max) ,@response_code int output ,@response_body nvarchar(max) output ,@response_header nvarchar(max) output)asbegin set @response_code = 200 set @response_body = 'Lorem Ipsum is simply dummy text of the printing'endPAT TokensTo integrate this concept, we can enable the created interfaces in the PAT (Personal Access Token) list. We could add a checkbox to specify which methods should be available through the PAT system. Swagger UITo facilitate developers interfacing with the newly created endpoints, we could provide two versions of the OpenAPI/metadata specification: one with the endpoints and another with universal endpoints. This would allow for straightforward integration with Swagger UI. What does this solve?Well currently you can make open api’s via processflows. But you need to model a processflow, then create a process procedure that handles the calls. And You need to think of everything to for example receive data as multipart forms, querystring data you need to split out of the routings e.t.c. It normally takes allot of code to make a simple webservice/api endpoint.