DEV Community: Linx Software

Sage Intacct Integration

Linx Software — Wed, 23 Nov 2022 14:15:21 +0000

Sage Intacct is one of the largest cloud-based accounting systems, offering a web service to facilitate integrations. This post covers how you can consume the Sage Intacct web services with Linx, a low-code backend platform.

Further reading: Why APIs and low-code are the perfect match

TLDR: Download the Sage integration template to fast-track your development.

Working with the Sage Intacct web service

This post covers a solution that retrieves a list of customers on sage using the Query and List Customers method.

Sage has good documentation on their web services and how to use them. As of the time of writing, the web service operates similarly to a REST service where you send XML requests.

The web service also has a token-like authentication method. You will need to obtain an access token before you can use any of the other methods. Thus before you make any calls, you need to call the getAPISession endpoint and provide your credentials. This will return a temporary session ID to be used with all other calls. This session ID is only valid for a limited time (specified in the sessiontimeout property in the response). We recommend that a session ID is retrieved in a separate function that you can reuse in all other integration functions on Linx.

Once you have a session ID, you can start to call other functions of the web service to do things such as retrieve customer lists, access accounting data and many other features offered by Sage.

XML vs JSON

The Sage web service expects XML requests. Users should note that when using the CallRESTEndpoint function, you should pay attention to format the XML precisely to match what Sage Intacct expects.

You can receive a response in XML or JSON based on your chosen version and configuration.

Calling Sage Intact Web Services with Linx

To start, we will call the web service with the CallRESTEndpoint function. The only trick is to format the request body correctly, as the web service expects an XML body. To do this, we will create a complex type, i.e. a structure that resembles the XML object. Once the structure is created, it is a simple matter of populating the values and then parsing them to XML with the XMLWriter function.

In our example, we will retrieve a list of customers using the Query and List Customers method. To do this, two things need to happen;

first, a session ID needs to be retrieved, and
the XML body needs to be constructed.

Authentication

Retrieving the session ID can be done by calling the getAPISession method. Creating a function specifically for retrieving the session ID will allow you to reuse that function whenever you need it.

In the example, the function created to get the Session ID is called generateAPISession. This function will receive the company credentials as input parameters (company ID, password and user ID). We created the type for this request using the Import functionality for types by importing the XML of the request body. After making a few adjustments (adding nodes that could not be imported), we assigned values to the type, mapping the credentials and required information. The function we also specified as . We also had to set the controlid property in the functions object. This can be done using a SetValue function after the type has been parsed to XML.

The request can be sent using a REST function, and you can import the response as a type to make things more manageable. This will allow easy access to the session ID that can be returned as the result of this function. Since the access function is reusable, it can be placed in the getCustomers function or any other function when you need to call the web service.

Get Customer List

Next, you can create the function to call the specific method you need. As per the example, we focused on getting a list of customers. This function is more complex than the generateAPISession function as data will be returned, and you might need to page through data (the maximum is 2000 records per call as of the time of writing).

To do this, we used a loop that will call the endpoint continuously until no more records are left. This was done by declaring the page size and offset. The maximum number of records are stored, and if the offset is less than the maximum number of records (the max page size), then it is assumed that there are no more records and the service does not have to be called again. The offset is also passed in the body of the call; this allows Sage to know from what record to return results.

The call is made with the response body set as JSON. When the response is received, use a JSONReader to map the fields to those declared in a custom type (this can also be imported). You need to add the received values to a list as part of the loop. This will ensure that values are not lost when the next iteration of the loop starts.

Note: There are several ways to do this. We chose this approach in the example.

Finally, once the list is complete and the data has been received, you can return the result or do what you need with the data. The beauty of reusable functions is that you can rely on that functionality later. Making your functions as small as possible allows for easier debugging and enhancement.

Use settings for fast-paced development

You may need to reuse a specific value across various functions during your development. In such a case, creating a setting will be helpful. These settings can be reused in many places. We made settings for all the authentication credentials, with some of them (specifically the password) being a secret, meaning the value will not be visible. What makes settings especially useful is that you can set them in the Linx Server to match a specific value for a particular environment. If you have a test server, you can use a different test version of your Sage credentials for that environment.

Now that you have a function to call the API and retrieve the required data, you can continue with your integration development. Storing the data in a database, making it available via a quick access REST API, formulating it for reporting or even integrating it into another application, the sky is the limit.

Final thoughts

Integrations come with unique challenges, depending on what system you need to integrate with, what you need to do with the data and what business rules you need to apply.

Working with the Sage Intacct API can be simplified by choosing a solution that allows you to streamline the web service call and manipulate the data. You can use the Sage Intacct web service with Linx to get the job done efficiently, and after you have the data, you can do what you need with it.

Get the templated sample solution in the Linx Github repo.

Image by https://unsplash.com/photos/djb1whucfBY

Getting an API to Production

Linx Software — Thu, 27 Oct 2022 13:15:59 +0000

When you do a web search for “how to build an API”, I found that quite a few options come up, but very few are end-to-end guides. This may be due to my poor web search abilities or because it’s quite hard to build an API (getting it from design to production).

Anyone that works with APIs will tell you that it can be quite the feat, and a team of people usually manages it. So building an API yourself and getting it into production so your users can start using it can be a significant challenge.

We live in a fortunate time where there are many tools that make this task much more manageable. With something like Postman, we can create the API specification, test the API specification and ultimately test our API to ensure that it is working as expected. To build the back end of our API, we will need a host of tools such as Flask, Heroku and more, or we can opt for a low-code tool such as Linx to build and host our API.

About Linx
Linx is a general-purpose low-code platform for building and hosting backends. Developers design and debug solutions in a familiar procedural style using a drag-and-drop interface with access to 1000s of ready-made functions. Solutions are deployed with one click to servers running in the cloud or on-premise. Further reading: Main concepts when using Linx

In this post, we will look at the process of building an API and how this process can be made more efficient.

API Development process

API development is complex, there is no way around it. Typically we need to design the API, code, test, debug, code again, test some more, deploy when we are ready, and then there is the seemingly endless maintenance. A typical API development life cycle will look something like this:

Each step in the process will typically be done by another tool or resource, so it can become quite an endeavor to implement an API.

For example, we might opt to use Postman to design our API (Open API Specification) and use something like flask for our code connect firebase or some database to store or retrieve our data. We might also need to make additional REST calls to other APIs and services. To test, we can use Postman again, but debugging the code and all our connectors can become troublesome. For deployment, we might opt for Heroku, but it depends on what our API requires. For monitoring, we can either create our monitoring system or use something like Splunk. And when we need to maintain our API, we need to dive back into all of that. You get what I am trying to say. API development is complicated.

Finding a better way

I wanted a way to simplify the API development lifecycle and to develop my APIs from design to production with only a hand full of tools. Thanks to low-code tools like Linx, this is possible. I was able to create an API, from design to deployment, using only three tools:

Postman I used postman for creating my API specification (YAML based) and for testing my API
Linx I used Linx to build my API, implement the logic, debug it and finally to host it. Quick note, you can also try your hand at building an API with this guided tutorial.
SQL Server SQL Server was used to store data for my API. I used the pre-created AdventureWorks2019 database and its data.

The requirement

I opted for a straightforward API that will do user record maintenance. The API has five methods:

Creating the specification

I created a straightforward API specification in Postman using YAML that matches the requirement. Postman allowed me to see what I created and visually provided additional information. Creating the API definition in Postman also benefits it already sets up that API for testing. If you choose to, you can set up the testing scripts at this stage.

Building the API

Now that I have the API definition, the code can be created. Linx allows you to import an OpenAPI 3.0 specification and will automatically generate the events for each method specified. I only needed to specify the URI and then build the logic.

Creating each event’s logic goes relatively quickly once the database plugin is installed. Linx does have a learning curve like every tool, but once you understand how to work with it, the pace picks up.

I added logic and functionality to each event for the API. For example, for the GetAllUsers method, we all needed to read from the SQL database and return the results via the response body.

Testing the API

Because the API is already set up on Postman, it was quite easy to test, in real-time, how the API operates now that the logic has been implemented. The GIF below shows how I used the Linx designer to debug the REST API I have created and how I am testing it in debug mode.

With the API being debugged in Linx, it’s being hosted so that I can call it to see how it will behave when I deploy. This allows me to test and get an actual result back:

Of course, we can also add test scripts in Postman to automate our testing process. These scripts will ensure that you are getting the correct response.

Deploying the API

Now that the API has been designed, developed and tested, it needs to be deployed. This can be a substantial task with traditional API development as we need to come up with a deployment strategy, figure out where we will be hosting what and make sure that monitoring and logging are taken care of and more.

My deployment was quite simple. I deployed the API from the Linx Designer directly onto the Linx Server. It took about 2 minutes for the solution to be built, pushed to the server, and ready for use. The difficulty of hosting an API is removed as the Linx server handles this. It also does monitoring and logging:

I called the GetUser method with an incorrect ID to see what would happen if an unexpected error occurred. The server logs the error and indicates with red that an error occurred:

I was able to call the API from Postman again, and the server gives an indication each time that the API is called.

Admittedly, I did not add any form of security or authentication to my API, but these settings are available in the Linx designer. Another option I tried was to generate the API Documentation in swagger format. This turned out to be quite valuable because by adding /swagger to the base URI, the documentation is available and hoasted with the API itself. This makes it easy to distribute API documentation when needed.

Wrapping up

When combining Linx and Postman, we can design, create, document and host APIs. It does take a bit of getting used to, much like any tool. Because Linx uses standard programming paradigms and jargon, it is easy to pick up if you are familiar with a programming language like C#. I do feel that we save the most time when deploying and hosting an API with Linx. Monitoring and hosting are done for you, meaning that a substantial headache is taken care of. If the logging and monitoring are not granular enough, you can add your functionality to the Linx solution.

If you want to try building an API with Linx, you can try it yourself

using design first (with Postman) or
code first (just build)

Low-code: Solving the Dark Arts of API Deployment

Linx Software — Mon, 03 Oct 2022 09:33:19 +0000

With so many approaches to proper API design, development, and management, it’s pretty easy to get lost just in the planning process. As an API provider, have you considered usage limits, gateway pricing plans, or security? Or, on a more technical level, have you thought about your current limitations, configuring frameworks, and web server infrastructure?

Putting an API into production comes with several challenges, regardless of your language and framework. For example, in traditional API deployment, you would be responsible for the hosting environment, which inevitably comes with concerns - you must maintain the infrastructure even if it’s hosted on AWS or Azure. Any infrastructure must be simultaneously deployed, such as database objects, files, storage configurations, and plugins.

For DevOps and developers familiar with AWS or Azure services, it can be faster to build with AWS Lambda or Azure Functions and run it behind their API management services. More of the infrastructure concerns are taken care of, but there are limitations on functionality compared to the language frameworks.

But for the day-to-day developer, API deployment and subsequent management is a considerable challenge, especially if it's not part of their immediate skill set.

Low code accelerates the API experience

The conventional approaches to developing software can take a lot of time and require arranging expensive and specialized tools and resources. The modern developer has several services and platforms to help when considering API development and hosting. You could use your favourite framework or language, or go for one of the popular platforms that specialize in only the deployment and hosting of the apps, or even try others such as Firebase and AWS, who provide a complete set of tools.

While these modern tools and services make developers more productive, there's still an 'app gap'. It's the gap between the code you have and the resources you require to build it, plus the knowledge, time, and cost associated with getting into production.

So it's not surprising, then, that low-code tools have become popular. Developers can build on familiar concepts, remove the complexity, and generally move faster with a low-code framework as their visual design framework and lack of boilerplate makes them much quicker to understand and use.

But besides building fast, low code is also about building right. These platforms eliminate many of the technical aspects of the API lifecycle, giving the developer much more control and visibility into the development process. They also are massive time-savers when faced with production. Platforms like Linx and Outsystems go even further, allowing you to build surprisingly powerful applications. They have several core features, such as integrating all types of data formats and providing prebuilt services and functionality to create complex - and often custom - backend applications.

Click to Cloud: Carefree API Deployment begins with Low-code

Three significant shifts happening today have accelerated the adoption of low code and its inherent power of deployment.

Infrastructure is moving to the cloud and becoming 100% software-driven (i.e., Infrastructure-as-Code)
Applications are getting more fragmented (micro-services)
An ever-increasing number of application functionalities have moved out of the developer’s code and into Platform Services, wholly managed by cloud providers.

These trends are often lauded as the gateway to the holy grail of digital transformation, but if your company isn't using CI/CD practices to streamline the software release process, testing and deployment are more often than not, time-consuming and difficult.

Low-code platforms streamline these processes as developers don’t need to worry about deployment, scale, or user experience. You still need developer-type skills to manage the infrastructure and architectural nuances of getting your application into production, but the timescale is considerably shorter.

Low code saves time and costs in deployment

About deploying APIs in particular, low-code removes the operational overhead that traditional development requires - i.e. no need for infrastructure - a major cost, plus it allows you to focus on your use case while providing easier and quicker solutions to several areas of development such as scalability, usage monitoring, security, etc.

Here’s how they help;

Hosting:

Nearly every vendor uses a reputable hosting provider such as AWS, Google Cloud Platform, Salesforce, or Microsoft Azure. Most will offer secure, highly available platforms and have completed third-party audits and certifications demonstrating their commitment to security.

Infrastructure Management:

Low-code vendors typically have some level of responsibility for managing the upper tiers of the overall stack. This helps the developer remove any concerns around hardware, security, availability, and more. Additionally, the platform most likely provides some form of dashboard, accountability, and change management capabilities.

Security:

A low-code tool is an excellent choice if you don’t know how to build robust systems to create, authorize, authenticate, and store users and their credentials. These elements can be complicated to understand and time-consuming to implement and maintain.

Updating & Maintenance:

Even the most basic of APIs is likely to require updating. This could require continued access to the code and a dedicated process for deployment. Most platforms provide this functionality, often moving from update to deployment seamlessly.

Deployment options:

An API can be deployed on-premise where it is operated and controlled by the developer or run serverless in the cloud. Each brings different challenges, and there are pros and cons for each. Understanding these environments and having the skills to create, configure and maintain the chosen environment is a considerable burden, often eliminated by the low-code vendor.

API management:

Managing a simple API or a complex system with multiple APIs - and their subscriptions - is a significant task. Additionally, the developer must consider documentation, usage limits, user policies, scalability, load-balancing, and more.

Ready to run?

Low-code platforms are fast becoming a promising alternative to traditional software development, even for professionals who work daily with mature products that are well-known, well-tested, and well-understood. It should be horses for courses, and low code may just be the perfect tool to help you expedite API-centric development.

Bonus

Experience low-code API development and care-free 1-click deployment by trying the Postman to Production guide. The solution provides an end-to-end process for taking an OpenAPI specification to a live server.

Watch: Specification to hosted API

Low-code and API development: The perfect match

Linx Software — Wed, 07 Sep 2022 08:58:02 +0000

There is an understated art to building good APIs – ones that are easy to integrate with, have high operational availability, offer readily attainable performance insights, and are easy to maintain. But if you have ever had to build an API from scratch, there is no denying that it is hard – and it gets much more complicated when you aim to deliver a quality API.

The API development process

Arguably there are three significant blocks when developing an API:

Designing the API,
Building the API and
Hosting the API.

In this post, we will look at each of these areas and break down the barriers in taking your API design into production. Before going into detail, it is essential to understand an API’s typical development process.

Typically, an API is developed in multiple phases.

API development tools

Just as the rise of RESTful APIs has been explosive, so has the rise in tools for creating, testing, and managing them. Whether you’re a newbie building your first API, or an expert racing an intractable deadline, there is a gamut of services to help you bring your API from concept to production. When looking to build and implement your API, each step might likely be done with a different tool or platform.

API Design

Several tools can assist in designing and testing your API. With many, you can visualise and test your OpenAPI specification, then automate API testing once it’s ready. Of course, you’ll still need to build the API, implement business logic, host it, perform monitoring, and document it.

Code, Implement Logic and Testing

When it comes to building the API, there are several ways to do this. Which one you pick will depend on the available skills, the feature set you need to support, time and budget. Low-code platforms are often a good choice as they tackle many notorious issues associated with development – and hosting – while also reducing engineering time and resources required.

For example, using a low-code tool such as Linx can simplify the API development process into just the use of 2 tools.

Try it! Take your OpenAPI specification to a hosted live API in 30 minutes including everything you need; low-code IDE, database, code snippets and live server.

By shrinking the number of tools you require to develop the API, the focus shifts from technical ability and mastery over a specific framework to ensuring that the business and complex logic operate as expected. Additionally, as low-code tools possess the additional benefit of speed of implementation, going from design to production can be far quicker than traditional tools.

Deploy, Monitor, Maintain

In the traditional API development process, the developer would be responsible for all the elements around hosting and management. Of course, you could opt for an IaaS platform where the basic building blocks are serverless functions like AWS Lambda or Azure Functions running behind their API management services. You would still need to code the API and have a good understanding of how APIs work, knowledge of the services offered by the IaaS platform and how they interact.

But when it comes to hosting and deployment, low-code platforms, again, come to the fore. Many offer all-inclusive features (one-click deployment, built-in security), in addition to being easy to start (ready-to-go infrastructure) and efficient (maintenance friendly).

How low-code solves the API problem

By using the right tool set, we can illustrate how you can optimise API development, from design to production.

Designing the API

Tool: Postman

Before you start building anything, you will need to design the API. By using the OpenAPI 3.0 specification, you can easily determine what interaction will take place and what endpoints will be available and in a matter of seconds, take care of your documentation. The OpenAPI specification can be created in either JSON or YAML format.

Choosing a tool such as Postman to design the API will provide many other benefits too, such as rich API testing. When the API is designed in Postman, that specification is pre-declared, meaning that testing will be much easier when the API is built. This gets much easier once a testing suite is created for the API.

Building the API

Tool: Linx

Development will involve creating the code for the API, implementing the business logic and integrating additional resources such as data sources or even making API calls.

When you import the OpenAPI specification in Linx, it creates the endpoints as events. Once the basic configuration is complete, you can start implementing the logic and integrations. For example, you can connect to a SQL Server database and retrieve data based on an input parameter.

Linx also allows for integration with nearly any data source or application. This makes it easier when you do need to make a call to another API, pull data from multiple sources or integrate your API with an existing system.

You can debug and test the API in real time with the Debugger throughout the development process. When debugging the API, a local session will is created where the API is locally hosted. You can use Postman to make API calls to the locally hosted API (using a localhost base URI). Doing this lets you quickly can see what the output will look like and if the API is behaving as expected. Running a version of the API that mimics how it will react when it is live will also allow you to spot and solve problems before they occur in production.

Hosting the API

Tool: Linx

There are many aspects to consider when hosting an API, such as scalability, security, observability and maintenance. There are also several hurdles to cross in deployment. For example, Python is a great choice for API builds, but it is surprisingly complex when deploying your app.

With traditional API deployment, you would be responsible for the hosting environment, which inevitably comes with its own concerns – you must maintain the infrastructure even if it’s hosted on AWS or Azure – and, any infrastructure must also be deployed at the same time, such as database objects, files, storage configurations, and plugins. Additionally, maintaining an API internally can lead to an unprecedented amount of overhead. So naturally, low-code platforms that include a hosting environment alleviate the inevitable time-cost-capability scenario.

Linx, being a platform, offers an application server where you can deploy, host and manage the applications created. With the platform doing the heavy lifting, your API can not only be deployed instantly but has time-saving, built-in functionality from the get-go – security, monitoring, logging and more.

The Linx Server will host the solution that you created. It also allows users to consume the API based on the configuration set up in the API specification, in addition to hosting a dashboard for observability and performance.

Bringing it all together

With Linx, like in traditional programming, you build the solution and control what needs to be done. You decide how complex or simple your process and API need to be. The advantage of doing it in low-code is the speed of implementation.

Check out our step-by-step guide if you want to try your hand at building and hosting an API.

Watch the video

Guide: OpenAPI 3 specification to Live API

Linx Software — Wed, 31 Aug 2022 09:48:50 +0000

User Guide: Go from Postman to Production

This guide will take you through the steps to design an API, build it, and deploy it to production. The process will take about 20 to 40 minutes to complete all steps. The project is to build a straightforward API to retrieve product data.

You will be provided with

The API specification,
instructions for what tools to use,
relevant scripts and
all steps to get the API live.

Requirements:

Build an API that retrieves product information from a database and makes that data available as a JSON object. The API will have two endpoints:

Get All products – This endpoint will retrieve all products in the database table
Get Product By ID – This endpoint will retrieve the relevant product record based on an ID that is passed in.

To follow this guide, you will need:

An installed version of Postman
An installed version of the Linx IDE Designer
Access to a Linx Server (provided when downloading the Linx Designer)

Setup: API Design and Postman Setup

IN POSTMAN
Every API needs to be designed before it can be developed. In this section, you will import the OpenAPI definition into Postman.

1. In Postman, Create a workspace for your project.

2. Go to APIs and create a new API named Product. Use the OpenAPI 3.0 Schema type and YAML as the Schema Format.

3. Define the API. This can be done by copying this API schema.Paste the copied definition into the Definition section of the API in Postman. Ensure that the schema is set to YAML and click the save button:

4. The API will be tested during development. To do so, create a Test Suite by clicking on the Add Test Suite button in the test section. Call it ‘ProductAPI’. A Test Suite is added in the Test section. Click on Add Test Suite.

5. You are now ready to build the API backend in Linx.

Using Linx: Setup and API Service

IN LINX

Now that the API definition is created and imported in Postman, we can create the API in Linx. This will be done via a REST Host service.

About Linx: A general-purpose low-code platform for building and hosting backends. Further reading: Main concepts when using Linx

6. In the Linx Designer, create a new solution. Add the REST plugin by clicking on the ‘ADD PLUGINS’ button within the Plugins Panel. Add a RESTHost service to your solution by dragging the RESTHost component from the Plugins tab, onto the central canvas.

7. Paste the API Definition (YAML) into the API Definition property.

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Product API
servers:
  url: http://localhost:5000
paths:
  /products:
    get:
      summary: Get all products
      operationId: getAllProducts
      tags:
        - products
      responses:
        '200':
          description: List of products
          content:
            application/json:    
              schema:
                $ref: "#/components/schemas/Products"
        default:
          description: Unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
  /products/{productId}:
    get:
      summary: Get product by id
      operationId: getProductById
      tags:
        - products
      parameters:
        - name: productId
          in: path
          required: true
          description: The id of the product to retrieve
          schema:
            type: integer
      responses:
        '200':
          description: The product requested
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Product"
        default:
          description: Unexpected error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Error"
components:
  schemas:
    Product:
      type: object
      required:
        - id
        - name
        - price
        - quantityInStock
      properties:
        id:
          type: integer
          format: int64
        name:
          type: string
        price:
          type: number
        quantityInStock:
          type: integer
          format: int64
    Products:
      type: array
      items:
        $ref: "#/components/schemas/Product"
    Error:
      type: object
      required:
        - code
        - message
      properties:
        code:
          type: integer
          format: int32
        message:
          type: string

8. Set the Base URI property (under the API definition property) to http://localhost:5000. Save the Solution.

9. Debug the REST Host service. Do this by selecting the RESTHost, and then clicking on the Debug button. When the debugger is ready, click on the Start button. This will start the service in a locally hosted instance for testing.

Further reading: Debugging a Linx Solution

IN POSTMAN

You are now ready to test the API for the first time. Along with these initial tests, the automated test scripts will also be set up.

10. Run all the tests. If set up correctly, all tests will pass, but there will be no further detail to view. This is because no tests have been set up. You will receive a “500 Internal Server Error” response from the API as no logic has been specified for the back-end process.

11. Add the tests to each of the methods. This can be done by clicking on the method and select the ‘test’ tab. The test functions have all been pre-created in this repo.

For products, add the test specified here
For productid add the test specified here
Run the tests again. The tests will fail as no logic has been specified for the back-end process. You will still receive a “500 Internal Server Error” response from the API.

Adding Logic: API Backend Logic

IN LINX
In this section, you will add logic to events so that each endpoint will return the correct data once called.

12. For the getAllProducts event:

a) Add the Database Plugin from the Plugins panel.

b) Select the GetAllProducts event by clicking on it.

c) Add an ExecuteSQL function by dragging the ExecuteSQL function from the Plugins panel onto the central canvas

d) Create a new setting for the database connection string. Call the setting DB_Connection and set its value to

Server=postmandb.twenty57.net;Database=postmanTemplate;User Id=Guest_User;Password=DwVHXx!sVeA9x52Mhus6Vfg?;

You can use your own database. Ensure to add the connection string as per above.

e) Set the connection string in the ExecuteSQL function to be the DB_Connection setting created above. It will then contain the value: $.Settings.DB_Connection

f) Set the Connection Type as ‘SQL Server’

g) Add the SQL below to that ExecuteSQL function:

     id
    ,name
    ,price
    ,quantityInStock
FROM dbo.Products;

Test the SQL script by clicking on the Test tab on the SQL box and executing the SQL. If successful you will be presented with a set of results.

Steps h to k set the response of the event to be the list of products returned by the ExecuteSQL function.

h) Set the return options of the ExecuteSQL function to ‘List of rows’

i) Add a SetValue function to the event underneath the ExecuteSQL function.

j) For the SetValue function, set the target as the result of the event, ‘$.Result’

k) For the source of the SetValue function, click on the edit button, then in the Response200 section, select ‘ExecuteSQL’ (the result of the SQL query from the function)

13. For the getProductByID event

a) Add an ExecuteSQL function

b) Set the connection to be the DB_Connection setting created above (in step 12). It will look like this: $.Settings.DB_Connection

c) Add the SQL below to that ExecuteSQL function:

SELECT 
    id
    ,name
    ,price
    ,quantityInStock
FROM dbo.Products
WHERE Id = @{$.Parameters.productId}
d) Set the return option of the ExecuteSQL function to only return the ‘First row’

e) Add a SetValue function to the event that will set the response body to the ExecuteSQL result. To do this, set the Target as ‘$.Result’ and for the source, click on the edit button, then in the Response200 section, select ‘ExecuteSQL’ (the result of the SQL query from the function) and save the solution

14. Debug the RESTHost Service

Testing: Testing the API

IN POSTMAN
In this section, you will test the API using Postman and ensure that endpoints return the data as expected.

15. Run all tests again. These should all pass. If you are receiving an Internal Server Error for getProductById, ensure that a suitable parameter is being passed for the Product ID. Making this parameter 1 should work as there is a product with ID 1.

Once complete, deploy the solution to a Linx server where it will be hosted.

Deployment: Putting the API into production

IN LINX
Now that the API is functioning as expected, it can be deployed to a server where it will be hosted and monitored. In this section, you will deploy the API.

Before you can deploy the solution and call the API from the Linx Server, the BaseURI needs to be corrected to point to the servers URI:

16. In the Linx Designer, select the ProductAPI RESTHost service, change the BaseURI from ‘http://localhost:5000’ to ‘https://+:8080’

17. Set the API Documentation to be Swagger UI. This will allow the server to host Swagger UI documentation for our API.

18. Rename the solution to ProductAPI. Do this by clicking on the solution in the solution explorer and then changing the name property then save the solution. This is important because it will reflect as such on the Linx Server with this name. Renaming it will make the solution easier to identify when you have more than one solution deployed.

19. Now that the API is developed and final changes are made, it is time to deploy it to a server where it will be hosted.

As part of your initial sign-up, you should have received login credentials for a trial Linx server via email. The Server is a Windows Service that hosts and manages your Linx Solutions and web services. You can install Linx Server on the hardware of your choice (on-premise or cloud) with monitoring, metrics and logging as standard. Further reading: Installing the Linx Server

To deploy your solution to the Linx Server, do the following:

a) In the Linx Designer, click Deploy
b) Set up the server using the credentials you have received
c) Click the Save button
d) Click the ‘DEPLOY & OPEN SERVER’
e) The solution will be deployed, and the server will be opened once the solution is deployed to the server.

These steps will only have to be taken the first time when setting up the server. After the server is set up with the Linx Designer, you can deploy by simply clicking on the ‘DEPLOY & OPEN SERVER’ button. You can also use the ‘DEPLOY’ button if you already have the server open.

20. When you open the Server, and the solution is uploaded and ready to use.

21. Click on the ProductAPI Solution, and then turn the RestHost service on.

22. Swagger documentation is hosted on the server and is accessible via any browser. You can access this by accessing the hosted API URL. The Hosted API URL is your server name ‘[my-domain].api.linx.twenty57.net‘. Add ‘/swagger’ to access the swagger documentation.

The address will look something like this:

https://xxxxxx11.api.linx.twenty57.net/swagger

See the Swagger documentation hosted on the Linx server:

Testing the Deployed Solution

You are now ready to test the hosted API

IN POSTMAN
In this section, you will test the hosted API using Postman and the automated tests that were set up.

23. Go to the ProductAPI collection and then select ‘Variables’

24. Change the ‘Current Value’ for baseUrl to be the URI for your server (same as in step 23). It will look something like the below with ‘xxxxxx11’ reflecting your server address:

https://xxxxxx11.api.linx.twenty57.net

Ensure that you save your changes to the variable by clicking the save button.

25. Call the products endpoint. The result will be a passed test.

26. Call the get products by ID endpoint with ID 1. This should now result in a passed test

27. To test how the server monitors failures and errors, force a call with a value that will fail such as ‘-1’. This will force an internal server error as we have not specified logic to catch this kind of invalid parameter.

You can now head back over to the Linx server to view the monitoring and logging of events.

IN LINX SERVER
With testing concluded, check the monitoring and logging done on the server.

28. Open the solution to view the events and errors in the dashboard. A green indicator indicates a successful event, and a failure or error will be indicated by a red indicator. To view errors, click on the red indicator on the dashboard. Alternatively, click on Log to view displayed errors.

You have now:

Designed an API and setup tests in Postman
Developed an API and tested it via real-time debugging
Deployed the API to a server where it is hosted
Viewed hosted API documentation
Tested the deployed API

Now it is time to start building your own API. You can start here or check out the full guide, Github repo or a video of the build.

Building an API? The 33 tools you need to consider

Linx Software — Mon, 25 Jul 2022 09:36:00 +0000

With APIs taking over, more people are asking: What can I use to create my API? Although there are many different API standards and types, we will primarily focus on REST APIs. An API can be as simple as a single endpoint with one purpose, or it can be much more complex, like the AWS APIs with 1000s of endpoints and 100s of thousands of users.

What all of these APIs have in common is that they have to be developed. We like to classify the development of APIs in 3 phases: Design, Build and Host.

Since REST is the most popular API interface, we will look at a REST API’s design, build and hosting. In this post, we will look at the 3 phases of API development and some valuable tools to assist you in your API journey.

Design, Build and Host your next API

REST APIs do not just exist out of thin air. It takes work to get one up and running. Luckily we can learn from those who came before us. Here are the three steps you need to plan for before building your API

Step	Input	Output
Design	User requirements	Specification e.g. OpenAPI3
Build	Design specification	Working code
Host	Working code	API live 24×7

Each of these steps has its own set of API design tools. Here are some I’ve used and popular alternatives

Design

INPUT: User Requirements. OUTPUT: Specification

During this phase, we need to ensure that you will create the API to fulfil a specific requirement. You need to take the user requirements for our API and transform them into a specification for our API. The result of this phase is usually some kind of documentation and an API specification. When designing the API, an outcome is the API specification. We prefer this specification to be OpenAPI.

“The OpenAPI Specification (OAS) defines a standard, language-agnostic interface to RESTful APIs, allowing humans and computers to discover and understand the service’s capabilities without access to source code, documentation, or through network traffic inspection.”

The OpenAPI specification is produced in either JSON or YAML. However, those specification languages do come with their challenges. For JSON, what bracket am I on again? And for YAML, how many spaces are there again for this object? Luckily, a few tools can help you create your OpenAPI specification:

Swagger: They have two options, the Swagger Editor (free to download) and Swagger hub (their hosted service). This service defines, visualises and validates APIs in a collaborative environment.
Postman: In their own words, “Postman is an API platform for building and using APIs”.
Insomnia: A free cross-platform desktop application that takes the pain out of interacting with and designing HTTP-based APIs.
Stoplight: Offers tooling across the API lifecycle that helps you build quality APIs efficiently.

Build

INPUT: Design Specification. OUTPUT: Working code

Now that we have defined what we need our API to do and have a specification, you can start building. For many, this is the fun part, creating the code that will execute when our API is called. Before starting any coding, ensure you know the logic you need to add to our API process. Business Logic is commonly used to enable:

Trigger automation such as email and push notifications on developer-defined changes in the data store.
Optimizing the data exchange with the app by joining multiple data collections.
Validating app user actions to enforce business rules.
Providing a means to host platform-agnostic code and save development time on multi-platform apps.

There are quite a few options here. You can choose to build your API with a full code framework such as NodeJS, Python: Django or ASP.NET.

Another option is to build your API with a low-code tool. I prefer Linx. A low code platform can allow you to quickly build the backend functionality of your API with pre-tested and proven components.

Before we get to building our API. Depending on your requirements, you might need to do a host of different things when your API is called. You may need to store data, send emails, use message queues and more. We will now take a look at a few tools that can be useful for building your API.

Data Storage

You will likely need to store data for your application. If you do not have an existing data storage platform, you might have some research to do. There are plenty of possibilities, each with its pros and cons.

AWS: AWS has a selection of database hosting options suited to various needs. These options can be quite scalable and flexible depending on your requirement, budget and technical ability
Azure: As with AWS, Azure also has various database options.
MongoDB: As per their website, “MongoDB is a document database with the scalability and flexibility that you want with the querying and indexing that you need”
MySQL: MySQL is an open-source relational database management system (RDBMS). It can be hosted on-premise, in the cloud (via a platform such as AWS or Azure), on a local machine or even in a docker container.
PostgreSQL: PostgreSQL is a powerful, open-source object-relational database system that uses and extends the SQL language combined with many features that safely store and scale the most complicated data workloads. It can be hosted on an on-premise server or by a service provider like AWS or Azure.

There are many other choices regarding data storage, be sure to pick the right one for you. A few things to consider are:

Do I want to host the database myself, or will it be hosted in the cloud?
Do I want to maintain the database myself?
What speed and scalability do I want from my data storage?

Utilities

You may also require some other utilities for your API, such as

Email platforms

Queues

Security

Consider Low-Code

The reasons to build an API in low-code are plentiful, but it mostly comes down to the time saved and simplicity. Tools such as Linx are a great fit for API development. It is a low-code tool for creating back-end processes, but it can also host and call web services. Some things you can do with Linx: Read, Create and alter files, perform data operations such as database read and write operations, integrate several different services and more.

The Linx Designer

Programming Languages
If you choose to go with a full code framework, here are some of the frameworks you can choose from when

.Net: ASP.NET
Java: Spring
JavaScript: Express
Python: Django
Ruby: Rails

If you haven’t recently tried a low-code tool I suggest trying one for your next small project. Pick something that you want to get out of the door quickly. Even better if you expect it to be mostly boilerplate. You might be surprised at how much they can improve your development speed.

Another interesting angle is building ‘serverless’ functions using AWS Lambda or Azure functions to implement the API. I’ve found that the architectural complexity eats a lot of time, but if you’re already familiar with those platforms, it might be an easy way to build a couple of endpoints.

Regardless of what approach or framework you choose, the outcome of this phase is working code that can be called to execute the API. For example, let’s say you require the API to return a data set from a data source (such as a database), the code will allow us to call an endpoint with a request body, and the code will retrieve the relevant data and return it to us. Since you are not hosting the API just yet, you will likely use “localhost”.

API Testing Tools

During the building phase, we need to test our API to ensure it is working properly. Here you have a few options:

Use a web browser: If your API is simple enough, this is possible, you won’t get the nicest output, but it will work in a pinch.
Hoppscotch.io: This tool makes testing your REST APIs much more manageable and is free to use when writing.
Postman
Insomnia

Hosting

INPUT: Working code. OUTPUT: API live 24×7

Now that your API is built and tested, you will need to ensure that it is reachable by your users. The simplest thing is to use a hosting platform that supports your programming language of choice. Services like

Or in the low-code case, the low-code platform does the hosting. These platforms usually have a few options to choose from, and if, with time, your API grows and needs more resources, contact the low-code platforms support team to find out what your options are.

This, of course, is not your only option. If you have an on-premise server, you can also opt to host the API yourself. It all depends on your ability to do so and risk appetite (since you are housing it by yourself, you will have to think of security and performance)

Final Thoughts

It is incredible to see how surprisingly easy things have become when compared to the way things were done just a few years ago. The thought of a time when you wanted a database, you needed to build it yourself or if you wanted to send a message through the internet, you required both a degree in mathematics, electrical engineering and computer science.

Now APIs are everywhere. They help us integrate third-party features, connect enterprise systems, and exchange data between apps. Learning how to build a rest API turns regular developers into digital superheroes. Today, you don’t need to be an experienced developer to build complex applications using high-performance parts with minimum effort and the minimum of code if you use the right tools.

Building a File Reader Process (via a REST API)

Linx Software — Thu, 14 Jul 2022 14:56:31 +0000

A common task for any IT department, or individual developer, is to move data from one location to another. A simple task to do once, but if this must be done many times for many different files (each with its own metadata, file type and data structure), it is a task that can become tedious. Luckily there are many low-code tools that can make this task much more manageable. As an example, Linx allows us to import a file and make the data available elsewhere quickly.

What is Linx
Linx is a general-purpose low-code platform for building backends like APIs, automations and integrations. It is an abstraction of programming itself and not domain, process or tooling specific. This means it can be used for any backend application in any domain with no limitations on connections to other tools and services.

In this post, we will look at a simple file import process with Linx and we will be making the data available via a REST Service.

The specification – a File Reader:

Before anything can be built, we need to determine what we need to build. I decided to go with a generic solution that every IT department will be sure to come across: A simple file importer that makes the data available for consumption elsewhere.

In a few minutes, I was able to create a little app that loads data from a CSV file and makes it available via REST API (As per the below GIF):

You can even host the REST Service in debug mode, making testing a breeze. Here is what you get when you call the service from a browser (using Postman will give you a much nicer testing experience; however for our purposes, a browser is fine):

Something worth noting is that Linx has moved towards a low code for developers model. This means that it is quite easy for a developer to use since it follows similar patterns and concepts as coding. One notable change in the new Linx designer is that lists now need to be initialised. All this means is that before you can assign or add a value to a list, you need to set the list to be empty. More details follow in the Creating the solution section.

Creating the solution:

We will be using three significant elements for this solution:

A Custom type to store our customer data
A Function that will read the file and return a list of customers (one customer per row in the CSV file)
A SimpleRESTHost to make the data available as a JSON object
The solution and CSV are available to download and tinker with. You can get it here.

Getting started

I generated the CSV File using an online data generator. The file is quite simple, with 100 records containing Name, Surname and Number fields.

I created my first function with the name LoadCustomers since we will be reading from the file here. A personal choice is to break down each task into its own process. I want to ensure that processes are as small as possible to make future maintenance, enhancements or debugging easier.

I also decided to create a custom type that will store my client’s information. Think of custom types as objects. When we create a custom-type customer, we are essentially creating an object that will contain the three fields of that customer record. These custom types are handled as JSON objects.

Loading the file

I added functionality in the LoadCustomers function to load the file. This process has its result set to be a list of customers. This means that after the process has been executed, we should be presented with a list of our 100 customer records from the file. The process follows these steps:

Initializer the output list
Create a separate list of customers
Read the file
Add the record to the list of customers
Assign the list of customers to be the output of the process To read the file, we do need to add the File plugin to our solution. This is simply done by clicking on the ADD PLUGINS button and adding the File plugin.

Something that I really appreciate is how lazy Linx allows me to be. The TextFileRead component has a great feature that allows you to load fields from the file. If your file has headers for each field, these headers can be pulled in and will be added to the field list. If the file is small like our example, this does not really help so much but imagine working with a file that has 52 fields.

Of course, you do not have to read from a text file. You can also read from an Excel file, PDF, database, Google Drive file (such as a sheet) and more. It all depends on your requirement.

After setting the result of my process to be the list of customers that we retrieved, we now have a process that reads the file and returns our customer data.

Now that we have the data, we want to do something with it. Now you have a few options. You can either read this into a database, reformat it, do calculations with it and write it back to a new file, create a report from the data, email it to a recipient, make the data available via an API and more. For our example, we will be making the data available via a REST API.

Making the data available via a REST Service

We will be using a REST service for our API, you can read more about the power of REST here.

Since we want to keep the process as simple as possible, I used a SimpleRESTHost component to build my API. We need to add the REST plugin to our solution before we can use this component.

If you want a bit more control and you are looking to create a Swagger file for your API, you can use a RESTHost component. This component will allow you to import the definition for the web service through a Swagger API description file.

You need to set a few things on your RESTHost:

BaseURI – I choose to create a Setting because it might need to change later on. Settings can be specified when the solution is hosed via the Linx Server, this way we can have different BaseURIs for each environment. Whatever you choose, the value should be “http://localhost:8080/service”
Operations – here you set up what operations the REST service will have, or defined otherwise, web methods. I created a customer operation that will return a list of customers in its response body. I use this event to return the data in the CSV file as a JSON object.

If you choose to use the SimpleRESTHost, Linx can generate the API documentation for you. You can choose the documentation either be generated as either Swagger or Redocly. This documentation can be accessed by calling the service and adding either /swagger or /redocly to your Base URI.

Because we already did the work of reading from the file and outputting it as a list, all we need to do now is call the LoadCustomers function and assign its output to the Response body.

You can also choose to enhance your solution by adding security, error handling and logging.

Debugging the solution

When ready, we can test our solution by debugging it. When clicking on the debug button the solution will be compiled. The debugger will highlight any errors that is stopping the solution from being compiled, but if there are none you are good to go. If you want to debug only file loading, you can select that function and click the debug button.

As with any good IDE, breakpoints are part of the Linx debugging process. You can add a breakpoint when in debug mode to stop the debugging process at a certain point. Do this by right-clicking on a component and selecting Add Breakpoint. This is useful when you want to review the process or view what variables or outputs are at a specific time.

To debug the REST service as we have illustrated above, select the SimpleRESTHost component and then click the debug button. Then click start. You can call the service from a browser, or Postman, by using the BaseURI that was set and the Path of the event. For our example, we use localhost:8080/service/customer.

As a bonus, here is the output of Postman when calling the REST Service:

What to do next

After we have debugged the solution and we are happy with the outcome, the solution can be deployed to a Linx server. The Linx server hosts solutions. This means that you do not need to run it on your local machine. Based on how they are set up, your solution’s processes, functions and services will also work on their own. As an example, the REST service we created will be available to be called by users. There are also other services such as timers, directory watches (if you want to monitor a directory for an event) or any other event monitor that you want to set up.

As previously mentioned, possible enhancements to this solution include:

Adding Error management. This can be done by adding TryCatch components to catch errors
Logging - To log successful and error events or to log the read data into a target data container such as a database
Data Quality and Cleanups
Notifications

More? The Linx solution and the CSV are available for you to download https://github.com/linx-software/HandsOnLinx6-FileImporter

How to build a generic Shopify API integration

Linx Software — Mon, 06 Jun 2022 12:52:33 +0000

You can use webhook subscriptions to receive notifications in a Linx Application about particular events in a Shopify store. After you’ve subscribed to a webhook, you can let your app execute code immediately after specific events occur in shops that have your app installed, instead of having to make API calls periodically to check their status. For example, you can rely on webhooks to trigger an action in your app when a customer creates a cart, or when a merchant creates a new product in their Shopify admin. By using webhooks subscriptions you can make fewer API calls overall, which makes sure that your apps are more efficient and update quickly.

Full solution https://linx.software/shopify-integration/
Sample https://github.com/linx-software/shopify-api-integration

How to build a REST API using Low-code

Linx Software — Mon, 23 May 2022 14:39:09 +0000

This video shows how to build, publish and host an API using Linx, a general-purpose low-code platform for backend development.

The video will show you how to

Quickly define and set up your API using our intuitive, drag-and-drop wizard.
Configure a REST API in just a few clicks using the built-in operation creator. No definition coding is required.
Host the solution

For more information, visit our website at https://linx.software

How to call SOAP Services using REST

Linx Software — Mon, 23 May 2022 14:12:50 +0000

SOAP, being a mature technology, has an extensive and often differently interpreted standard set. This makes it an excellent tool for corporate users to manipulate data into their precise requirements and technology stack. However, for public consumption, this causes issues that sometimes are difficult or impossible to solve without changing code. A good example here is that SOAP is allowed to define the same type in some standard interpretations in different XSD files. However, when trying to use this in other interpreters, it will most likely crash.

To solve this, we need to look at SOAP a little bit deeper. In essence, SOAP, as a technology, is simply a Web (or HTTP) POST call with a specifically formatted XML payload, which the SOAP server is expecting and understands. It then returns a specifically formatted XML response which the client then can parse and use.

You might be saying, ‘Hey, that sounds very much like a REST call,’ but that is exactly what it is. Instead of an API reference, which gives you the Request and Response formats and requirements, SOAP publishes a WSDL. So if you’ve got one of these SOAP Services which breaks standards, if you can get the text of a successful Request, you can use REST to make the call with that request body.

Below is how to implement this technology in Linx, a low-code platform for backends.

Background - https://linx.software/soap-to-rest/
Linx solution - https://community.linx.software/community/uploads/short-url/nN1SP5FaN36GUZY9aPCjNbnh7SL.lsoz

How a team of two developers built 33 API projects in a year

Linx Software — Wed, 13 Apr 2022 11:29:28 +0000

In developing networked applications either on the web or mobile (or both), most developers choose to access their backend data and services through REST API endpoints. By keeping the data storage and processing off of the client application, you can ensure a faster user experience. But building out REST API endpoints and backend services can take a lot of precious time that you could spend building out better business logic, optimizing performance, or eliminating tech debt.

Much of the code around REST APIs is boilerplate — the same classes, methods, and functions with different data. Pretty tedious stuff. We’ve talked to a lean team of two developers who managed to build 33 REST API projects in a single year by using a better API builder.

In this article, we’re going to let you how they got to be so efficient.

Building beyond boilerplate

Let’s face it — most APIs do basic CRUD (create, read, update, and delete) operations on a database. We could cut a lot of the work out if we could abstract away the logic that connects to a database, select the fields that we need, and format it in a JSON object for transport to the requesting client application. All we really need are the cells in the database to pull data from and the fields in the JSON object that correspond with them.

Linx is a general-purpose low-code platform that does exactly this. It’s a low-code desktop application that speeds up the process of building out backend services. With a single click, you can create a barebones application, then start adding the pieces visually, which saves time jumping back and forth between code files. When you add the REST plugin, all you need to do is define the essentials of the REST API: where the endpoint is hosted, the request method, the data objects it returns or consumes, and the SQL database that it draws data from. You still need to write the SQL queries; this is low-code, not no-code.

Just like that, a whole slew of concerns about your API endpoints have been handled. Security and authentication are built-in, automatically managed in each request’s headers. Deployment is easy, so you don’t have to fiddle with build processes or a complicated CI/CD pipeline. Versioning and monitoring — all that is built into the application.
Not every API sticks to CRUD operations. Linx doesn’t hide what’s going on under the hood with the REST API code, it just creates it quickly. So if you need to create more complicated logic behind one of your routes, you can edit the code and write it yourself.

Learn more

As developers, we like building new things over buying pre-built solutions. We like solving our own problems. With a solution like Linx, you can get the best of both worlds: You can solve those problems faster without having to fuss with the repetitive tasks that come with any REST API project.

For a detailed walkthrough of how to build a low-code REST API in Linx, check out these resources

Tutorial: Consuming REST APIs in low-code
Guide: Build and host a low-code REST API
Watch:Building an API (using OpenAPI definition)

Linx 6: Sophisticated Low-code for Developers

Linx Software — Fri, 18 Mar 2022 11:24:21 +0000

Seven years ago, we announced Linx 5, a release specifically designed to modernise and commercialise an internal tool we had been using with our enterprise customers for the previous 15 years. By all accounts, Linx 5 was a huge success with our customers and partners.

MORE: Building a backend: Why Linx should be your got-to low-code platform

Highlights of the new release include;

Overhauled UI and dark theme

One of the most requested features on our list! Creating a dark mode version for the Linx Designer was a huge endeavour as we had to carefully design and craft every component and screen. As a result, the new scheme provides a modern look in-line with what the professional developer expects in a software tool.

Diffable solutions

Larger teams have found it challenging to work on a single Linx solution because there was no way to look at the differences between versions. Linx 6 fixes this by saving solutions to text files in a folder structure so teams can use their diffing tool of choice to inspect changes. In addition, low-code teams can now use the same workflows developers use to pull, change, review, and commit changes.

More control over function result types

One of our goals at Linx is to close the gap between the flexibility of hand-coding and low-code, and this is one of those rare changes where making Linx more flexible also makes it simpler to use. Linx 5 returns values from a Linx function as properties on a result object. If you want to return a string, the result object would contain a string property. You would use the string by referencing “function-name.result.property-name”.

With Linx 6, we’ve added the option to return any type, so you can return the string value as-is. You would reference it as “function-name”, which is much simpler and more closely resembles how common programming languages treat results from functions.

Simplified solution layout

We’ve removed the Project concept as it’s functionally no different from a Folder. This change reduces clutter in the UI and makes simple solutions simpler while complex solutions can be organised using Folders.

Decouple solution dependencies from the Designer

In Linx 5.14, we released versioned plugins to afford more control over plugin updates. Linx 6 brings the same concept to our compiler and type system. Most production-grade software has several dependencies that need to be tightly managed between development, testing, and production. We’ve decoupled the compiler and type system from the Linx Designer and Server and made them dependencies of the solution.

This change allows more control over solution dependency updates, providing a more reliable experience when working with a solution and less chance of unintentionally breaking something when deploying to a different environment. It also allows more granular updates to Linx, enabling a faster release cadence.

To check out the new version of Linx 6, download the IDE

Click here for the full Linx 6 release notes