Wizzdi Cloud simplifies and accelerates application development by enabling users to deploy products anywhere without code dependencies.

1. You Built It; You Own It: Wizzdi Cloud differs from almost all no-code platforms because it doesn’t restrict users to its ecosystem. After creating an App with Wizzdi Cloud, you can deploy it elsewhere. You can take your code and work on it independently without returning to Wizzdi Cloud. Choose to modify or build upon your project outside of Wizzdi Cloud. You can do so easily. Especially with the Spring Boot runtime, your code will be free from Wizzdi-specific dependencies, ensuring standard coding practices are maintained. Once you choose to develop outside the Wizzdi Cloud while keeping the use of Wizzdi Cloud available, the system automatically integrates any external code, allowing you continuous access to Wizzdi Cloud’s advanced visual tools.
2. Wizzdi Cloud provides a comprehensive, no-code backend development platform; front-end development is coming soon. Here’s what it offers:
   1. Quality Assurance: The backends created are top-notch, aligning with industry standards.
   2. Flexibility: Wizzdi Cloud is feature-rich yet flexible. Backend systems can optionally be refined and extended outside the system.
   3. Tailored Solutions: While the platform caters to a wide range of needs, specific requirements might arise based on an organization’s unique technical background. Wizzdi Cloud is designed to be a starting point, allowing for such external enhancements. However, accessing standard libraries and code is supported in the platform, including a code editor for users preferring to code some parts of the system.
   4. Risk-Free: Choosing Wizzdi Cloud carries no risk. It serves as a robust foundation, ensuring that users have the flexibility to expand and enhance their projects as required.
3. AI integration: Wizzdi Cloud offers seamless integration with ChatGPT, allowing users to transition from problem descriptions to diagrams easily. ChatGPT integration is available in someplace and will be expanded in subsequent versions.
4. Deployment: Users can transition from diagrams to deployment on the Wizzdi customer high-availability cluster without coding. They can also pull their code and deploy it elsewhere using the Docker script.
5. UI Builder: A UI builder tool will be available in H1 2025. Wizzdi Cloud User Interface builder is designed to create Google Flutter-based mobile and web applications.
6. Hosting Options: The backend system can be hosted on-premises, in a user’s cloud, or the Wizzdi Cloud. It includes a one-line Docker boot option for easy deployment of Linux, Windows, and Mac.
7. Repository Integration: The platform integrates with popular repositories like GitHub, GitLab, and Bitbucket.
8. Development Patterns: Wizzdi Cloud supports multiple development strategies: full no-code development, a combination of no-code with traditional development, or using the no-code system as an assistant tool in the development process. This allows Wizzdi Cloud to contribute to the code base like any developer.
9. Reusability: Wizzdi Cloud is intended to facilitate reuse on a broad scale. This encompasses projects created by yourself and others using Wizzdi Cloud and the ability to access available artifacts from private or public repositories such as Maven Central, which houses over one million software artifacts.
10. External Services: Wizzdi Cloud includes extensive support for accessing services such as Google, SendGrid, and others; additionally, it supports importing the definitions for every available external service.
11. MarketPlaces: Wizzdi Cloud supports public and private marketplaces. When apps are published to a marketplace, eligible users can clone or import them into any of their workspaces and use some or all of the app elements in their apps.
12. Runtimes and Multi-tenancy: Wizzdi Cloud has three run-times: Pure Spring Boot, FlexiCore Boot, and FlexiCore. FlexiCore Boot and FlexiCore are extensions of Spring and come with an integrated multi-tenancy system. This system allows role-based access control to both data and API endpoints. Both are open-source and can be found on FlexiCore.The multi-tenancy in FlexiCore enables authorized users to combine data from different tenants and supports hierarchical structures. However, the Pure Spring run-time doesn’t have this multi-tenancy feature. All FlexiCore-based run-times work with standard Spring Boot libraries and development patterns.
13. Security In pure Spring runtime: Role-based access to API endpoints is also supported, and optionally so, users have access to data they have created only. App builders can define the roles and their access to the API endpoints.
14. New features and bug tracking: Use the TODO support to allow stakeholders to describe new features and report bugs in your Apps. The unique backtracing feature tracks all the changes related to a specific TODO.
15. Metrics: Support Spring Metrics. Spring Metrics is a feature of the Spring ecosystem that provides powerful tools for monitoring and managing application performance and behavior. It is often used with tools like Micrometer, Prometheus, and Grafana to collect, store, and visualize application metrics.

Note On Hierarchical Multi-Tenancy: 

Hierarchical multi-tenancy refers to a structured, tree-like organization of tenants within a system. Unlike the traditional flat model, where all tenants are at the same level, the hierarchical approach allows for nested multi-tenancy. In the context of Wizzdi Cloud and its support for hierarchical multi-tenancy, tenant administrators can create additional tenants within their primary tenant. This nesting can occur to any depth, depending on the organization’s needs, application, and system policies. For instance, consider a large organization that operates globally. The top-level tenant could represent the global enterprise. Beneath that, regional tenants could be created for North America, Europe, Asia, etc. Within the Europe tenant, further sub-tenants could be established for individual countries like France, Germany, and the UK. And even within those country-level tenants, you could have more granular tenants representing different departments or offices. Any users granted the correct permissions, such as an administrator of a tenant, can access the data on the tenants created in the tenant he administrates and ‘below’.

The post Wizzdi Cloud User Guide first appeared on wizzdi.

The post Login/Register first appeared on wizzdi.

An App consists of backend and front-end components, forming a complete software application.

You can search for your apps in the ‘My Apps’ view. Apps are arranged in Workspaces, and you can invite other users to your workspace while controlling their permissions. The latest workspace used will be the default one when you log in.

The Walkthrough

When starting the system the first time, you will be offered a walkthrough of the system, where you will be guided in building a simple yet complete backend.  You can always start the walkthrough from the top right menu. When stopped, the current walkthrough can always be resumed unless discarded.

The post My Apps first appeared on wizzdi.

In the context of Wizzdi Cloud, an “App” represents a holistic software solution, encompassing its back-end and front-end facets.

Back-end Components

• These form the engine room of your app, managing the underlying logic, databases, and integrations.
• Deployment Flexibility: With just a click, these components can be deployed either on Wizzdi Cloud’s infrastructure, your cloud setup, an on-premises server, or even directly on a laptop.

Front-end Components

• This refers to the user interface – what the end-users interact with.
• Deployment Options: For mobile applications, the front end can be rolled out on platforms like the Apple App Store or Google Play. Conversely, for web apps, the front end is deployed as static files residing on the back-end infrastructure.
• The current version of Wizzdi Cloud doesn’t include the front-end tools; these are planned for Q4 2024.

UI Development & Integration

• While Wizzdi Cloud’s UI builder is in the pipeline, users aren’t limited in their choice of interface design tools. You can craft the UI using your preferred software and subsequently integrate it with Wizzdi Cloud, which serves as a backend.

API Exposures

• The deployed back-end doesn’t exist in isolation; it provides a REST API suite, allowing for flexible integrations and interactions with other software or systems.
• These APIs are accessible via our integrated OpenAPI/Swagger interface, which offers a clear, interactive representation of the available endpoints. This facilitates understanding and testing.

In essence, Wizzdi Cloud offers a platform that encapsulates an app’s operational core (back-end) and user-facing layer (front-end), allowing developers and organizations a streamlined approach to app development and deployment.

Design Approaches

 Domain-First Approach

A domain-first approach emphasizes the importance of understanding the data structure of the system you want to create. Here’s how it works:

• Begin with the Basics: Using Wizzdi Cloud’s intuitive diagramming tools, you’ll outline your domain model. This means identifying the core entities or ‘Things‘ that your system will interact with.
• Intuitive for Domain Experts: The appeal of this approach is its accessibility to domain experts — those who understand the requirements of an application from a functional perspective rather than a technical one. Take, for instance, a school principal: She would intuitively know that managing a school involves entities like Class, Classroom, Teacher, Student, Subject, etc.  See: Wizzdi Cloud for Domain Experts
• Seamless Backend Generation: Once you’ve established the entities and their interrelationships, Wizzdi Cloud takes over. A functional backend is generated automatically, with all necessary APIs to manage these entities. This can be grasped visually when running the Walkthrough.

 Contract-First Approach

The contract-first method flips the script by focusing on user interaction first. Here’s the breakdown:

• UI as the Starting Point: Instead of diving deep into the domain model, this approach starts with the user interface design. This design process inherently outlines the services that the backend needs to provide.
• Service Definition through OpenAPI: The next step usually involves defining the services following the UI design. This often culminates in creating an OpenAPI document, a contract for what services the backend should offer.
• Direct Integration with Wizzdi Cloud: Wizzdi Cloud can directly import and recognize the OpenAPI document. Upon importing, a set of exposed APIs materializes in the system. Subsequent steps involve fleshing out these APIs — linking them to specific business logic, integrating with other systems, drawing up custom queries, and aligning them with the eventual domain model.

Whether you’re a domain expert wanting to shape a system around core entities or a designer aiming to sculpt backend services based on user interfaces, Wizzdi Cloud accommodates both avenues, providing a robust platform for achieving your visions.

How to

Create an App

Click on the + new APP button and fill in the required fields for the app.

The New App button.

Once clicked, the Create New App dialog is presented; enter a name for the app.

The advanced section is discussed later in this document.

The App creation may take a while (20-30 seconds); thanks for being patient.

The Overview

App Overview.

App Details

The App details are displayed at the top left corner of the APP Overview.

At the top right, you can see the current version you are working on and the APP runtime; Wizzdi Cloud supports three different runtimes. See below in this document.

Maven Coordinates

Each App has a unique designation comprising two values and the version. These are called Maven Coordinates:

• The GroupId and the Artifact Id. The group Id is usually in the form yyy.xxxxxx
  and the [yyy] is one of com, org, tv, etc. This is similar to the suffix of a URL.
  The [xxxxx] is usually the name of the company or organization owning the App.
• The Artifact ID uniquely designates the App within the group.

Package Name

Whether you ever look at the code or not, Wizzdi Cloud generates code. This is done under the hood; most users need not be concerned.
The code for the backend App is structured in packages, where the package name across all parts of the App typically begins with a predetermined prefix.
The convention is similar to the Group ID.

The default group-id and package name can be set on the user account.

Color

The color for the App in several locations in Wizzdi Cloud.

Icon

This is the App’s icon, which Wizzdi Cloud randomly assigns. Follow the steps below to select a different icon.

Static UI

The current version of Wizzdi Cloud does not have a UI builder for the client-facing side of the application. However, once the initial version of the server is available, you can develop a front-end web application using any available tools and upload it here. Once the back-end application is deployed, the front-end application will be served to users.

Editing the App Details

Click on edit details to edit most of the above items.

Editable items

App Name.

App Description.

Group Id.

Package Name.

Artifact Id.

App Color.

App Icon.

Static files.

Deployment Status

This is a collapsible panel providing information on the deployed app.

Accessing the Commit operation from this area is possible when the app has never been deployed.

When an App is committed successfully, it becomes ready for deployment.

Deployment panel: when the app is deployed, uninstall becomes available.

Click on the small arrow (marked by a yellow rectangle) to open the panel.

Deployment Panel when the App has never been deployed.

If the App was deployed at least once and has not been uninstalled, the deployment panel has more information:

Deployment Panel is when the app has been deployed at least once.

App Url

This is the URL of the static files when deployed on the Wizzdi Customer Cluster, in case they were uploaded.

Swagger Url

This URL should always be available and provide the standard Swagger interface for accessing the deployed server’s exposed API. Once you display the Swagger interface, you can get the OpenAPI document.

App Version

The currently deployed version. For information only.

Docker Image

The currently created docker image that was deployed on the Kubernetes cluster. For information only.

Chart Version

A chart is a collection of files describing a set of Kubernetes resources.
The displayed version designates the version used for deployment. For information only.

The App Building Process

This panel provides access to some of the editors related to the back-end app-building process. This list is for first-time users who need help understanding the next step. You can access the Walkthrough from the top-right menu to see the order of using the editors.

Create your domain model.

If you’re not using the contract-first approach, preparing your domain model is the first and mandatory step. Once your domain model is ready, you can commit and deploy your app. After deployment, the back end will include the API endpoints that manage the entities within the domain model.

Add business logic

In most cases, the API endpoints resulting from the domain model will not be sufficient to meet all the project requirements. Therefore, you may need to add additional business flows to enhance the functionality of your application.

Business logic diagrams can help you add extra logic triggered by various events such as data creation or updates, scheduling, webhooks, other business logic events, or messages arriving through Kafka, Websocket, and MQTT.

Add Consumed API

We utilize the Consumed API module to access external services like SendGrid or Google. You have two options for creating the full API: either use the OpenAPI import support or define the external API endpoints one by one by following the documentation provided by the external service. This step is only required if you need to access these external services.

The Business Flow diagram tools currently offer several predefined External API endpoints. If a service is unavailable in the already imported APIs, you can always import or create it yourself.

Setup your GIT repositories

This step is mandatory before deploying the created app or accessing the code on a repository. You must grant Wizzdi Cloud access to a remote repository available on Github or a similar service.

Marketplaces

Additional panels.

You can publish a committed App in your marketplaces to share your work with others. Unlike workspaces where several people can work and access the same app, publishing in a marketplace saves a frozen version of the app. This allows others to clone or import the App, modify it, or access its functionality from their apps. You can find more information about marketplaces in the marketplaces section.

Data visualization

This section contains statistics about the current application.

Click the small arrow to the right of ‘Data Visualization’, and a similar view to the image below should appear:

Data Visualization when hovering over the Entities slice.

Hover over a pie slice to view statistics on the element type it represents.

Statistics

Provides some statistics on the created code. It should be noted that Wizzdi Cloud generates code before an App can be deployed. Some users will enhance the code; others will never see it as they prefer a full, no-code workflow.

Code Generated example.

The App Tools Menu

This is a short description of the tools available to build an app.

Legend

1. The Domain Model Diagrams editor is where you define entities and their relationships. Following this step, your APP crud services and APIs are automatically created by default.
2. The consumed APIs section defines external services your App can access, such as Google Services, Slack, and other servers. Several such APIs are available by default and require no additional definitions. Consumed APIs can be imported from OpenAPI documents or manually constructed here.
3. The Exposed APIs section manages the APIs your APP exposed. These include automatically created crud APIs, imported OpenAPI documents, or manually constructed ones here.
4. The Runtime instances section is currently unavailable. When a target server starts for the first time, these are used to create default data in the database. Some default data, such as roles and tenants, can be defined elsewhere.
5. The Custom Queries section defines complex queries on your entities using an easy-to-use interface. Queries translate to Java criteria API and, when executed, to SQL.
6. The Depedencis Section defines the modules your app uses. These include automatically added modules, such as Spring libraries, and any public or private Java binaries you want to access from your App. The most common source for such libraries is Maven Central.
7. The Components section lists the App components. For Spring runtime, a single component is available and is automatically created by Wizzdi Cloud. Flexicore-based runtime supports runtime plugins, so plugins can be designed using this feature.

The post App first appeared on wizzdi.

The domain model is a conceptual framework that outlines the different entities, their attributes, relationships, and constraints that govern the problem domain of a specific application or system. It acts as a blueprint for comprehending, documenting, and communicating the structure and semantics of the application domain space.

Essential aspects of a domain model include:

1. Entities  These are the primary elements within the domain. For example, in a banking application, entities might include Account, Customer, Transaction, etc.
2. Fields: Characteristics or properties of entities. For example, a Customer entity might have fields like name, address, and phone number.
3. Relationships are connections between entities that indicate how they interact or are related to each other. For instance, a Customer may have one or more Orders.
4. Inheritance Associations: This refers to the relationship between two entities, where a child entity inherits fields from a parent entity.

Creating a domain model is often one of the initial steps in the design phase of software development. It helps stakeholders understand the system and provides a foundation for the development of the system’s architecture and functionality. This approach is especially prevalent in methodologies like Domain-Driven Design (DDD), which focuses on developing a rich understanding and model of the domain as a core to the software development process.

Application Domain Experts can create the domain model using the tools provided by Wizzdi Cloud as long as the concepts of entities, fields, and relationships are understood. It is easy to apply changes to the existing and deployed App, reflecting changing requirements or a more profound and better understanding of the application domain.

The domain model in Wizzdi Cloud is managed through one or more Entity Diagrams. This arrangement depicts the app’s data architecture and the relationships between different data entities.

Upon finalizing the domain model, the app is ready for deployment. This process exposes a CRUD  API, which facilitates the management of the entities defined in the domain model. Any adjustments made to the domain model automatically result in updates to the API endpoints, reflecting the changes without manual intervention. This early version of the APP includes the required API endpoints to manage the created entities.

Users will likely introduce additional APIs, services, and functionalities using Wizzdi Cloud’s built-in tools or incorporate custom code using their preferred development tools. Regardless of the method chosen, updates to the domain model and the corresponding APIs are seamlessly integrated into the app. Wizzdi Cloud maintains continuous synchronization with the developers’ modifications, ensuring the app remains consistent with the evolving domain model.

• Entity Diagrams: Within the domain model section, you can create multiple entity diagrams. These visual representations help you understand and design your system’s core data architecture.

Overview

Start the domain model editor by clicking on Domain Model in the app’s side menu.

1. This is the diagram’s name; you can use #10 to edit the name. The small [x] lets you remove the diagram from the view; the diagram is NOT deleted and is still available when adding a new diagram.
2. Add a new diagram; if diagrams have been removed, they appear for selection.
3. Zoom out. You can also zoom out using the mouse wheel.
4. Restore the view to 100% zoom.
5. Zoom in. It’s worth noting that you can also zoom in using the mouse wheel.
6. Undo
7. Redo
8. Auto-arrange the current diagram.
9. Make the view larger; the left-side menu is made invisible.
10. Rename the diagram.
11. Add a description to the diagram.
12. Add a new Entity.
13. Import an Entity or an Enum; Import items from the current or referenced projects into the current diagram.

Entities

Create an entity using right-click

The New Entity has a name field. Entity names must start with a Capital letter. The right-side menu provides a Description field for the currently selected entity.

Once an entity is created, the following tools and actions are available. The same action is often available from multiple places.

1. Warning indicator: hover over the icon for more information about the warning.
2. Additional actions menu.
3. The entity can be renamed by double-clicking on the name; editing is then available. Renaming an entity is also available from the right-side menu.
4. New field button. Add a new field to the entity.
5. Connect to other entities, which will be discussed later in this guide.

This menu is available from the three dots button on the entity.

1. Add a new field. This option is available from the bottom of the entity thumbnail and the right-side menu.
2. Entities can have indexes added to improve data retrieval speed. Refer below for additional information.
3. When creating an entity relationship involving entities from multiple diagrams, copying and moving entities to another diagram is necessary. This operation concerns only the arrangement of entities on diagrams.
4. Move to another diagram, similar to the previous section, but the entity is removed.
5. Change the color of the entity in the top bar. It helps in better organizing the diagram.
6. Remove from diagram; Remove the entity from the diagram. The entity is not deleted.
7. Delete the entity. The entity is deleted and removed from all diagrams.

Inheritance

Wizzdi Cloud supports inheritance, a cornerstone of Object-Oriented Programming (OOP). In data modeling and entity structures, inheritance allows one entity to inherit attributes or characteristics from another, establishing a hierarchical relationship between them.

For example, if there’s a base entity named ‘Vehicle‘ with attributes like speed and weight, a derived entity such as ‘Car‘ can inherit these attributes and might introduce new ones specific to it, like trunk size. By supporting inheritance in Wizzdi Cloud, users can create data models that depict these structured, hierarchical relationships, ensuring a more organized and intuitive representation of data. Furthermore, Wizzdi Cloud adeptly manages the underlying complexity of handling inheritance at the database level, abstracting these intricacies from the user and providing a seamless experience.
Furthermore, it’s important to note that inheritance is crucial in reusing domain models you or other users created on the Wizzdi cloud or available from the Wizzdi or other marketplaces. Through inheritance, you can modify and improve upon the original design of these models.

Inheritance example: Vehicles Cars, and Motorcycles

To create an inheritance link between an entity and its Super Entity, select the entity, drag the small circle on top of the Entity shape, and release it above the name of the Super Entity.

An entity can have only a single Super Entity.  A single Super-Entity can have multiple ‘children‘ entities.

Click on the three dots menu to detach an entity from its Super Entity. When an entity extends a super entity, all fields from the super entity are automatically inherited and visible within the extending entity. This inheritance can cascade through multiple levels or layers of hierarchy. It’s important to note that once fields are inherited, they become unchangeable on the child entity. To modify these fields, one must navigate to the original super entity where they are defined, even if this means moving up several levels in the inheritance chain.

The parent entity in the inheritance hierarchy can be a Mapped Super Class. 

A Mapped Superclass is a model from which other entities can inherit properties and mappings but is not itself an entity. It does not have its database table; instead, it allows its subclasses to inherit its properties, ensuring that these properties are mapped to the columns of the subclasses’ tables. This approach helps define standard fields (like id, name, description, createdAt, and updatedAt) across multiple entities without duplicating the mapping information in each entity class. This option should be preferred if you never need to manage the mapped superclass directly. For example, suppose the Mapped Super Class Base is defined to hold standard fields across multiple entities such as name, description, createdAt, and updatedAt. In that case, there is no need to manage the Base entity directly, as this entity is created only to save extra typing and make the refactoring of standard fields easier.

When a Superclass is not a Mapped Superclass, it and all its subclasses share the same table, with a discriminator column to differentiate between them.

Remove/Edit Inheritance

Lines connect the super-entity with its children when entities are related through inheritance. These lines can be hidden to simplify the diagram.

A child entity shows its super-entity to the right side of its name; in the example above, Base extends Country, and SuperBase extends Base. When the inheritance line is clicked, a menu pops up. The inheritance can be deleted or hidden.

All inheritance lines up to the top become invisible when hidden, yet super-entity names remain visible on the entity top bar.

Click the name of the super-entity on the right side of a ‘Child’ entity name to display a menu for showing the inheritance line up to the next level by Show or show all the inheritance lines through the top by Show All.

External Entities

to import an external entity from a dependency (see project dependencies) by using either the import external button on the right side or by using the context menu on a visible space of the diagram,

Import an entity or enum

Use Internal to import Entities from the current App.

Use External to import from dependent apps.  These are Apps added to the Dependencies section.

Enums

When creating a domain model, we sometimes prefer predefined values over entities. For instance, for Gender, we might list:

• Female
• Male
• Undisclosed

Enums should be utilized in scenarios where the set of possible values is determined at the time of the application’s development, and there’s no anticipation of modifying these values post-deployment. Altering an enum necessitates updates to the application or its underlying code, reflecting a more static or immutable approach to handling certain data types.

Conversely, a dedicated table or entity structure provides a dynamic framework for managing possible values. This approach allows authorized users to add, remove, or modify the values as required without requiring direct App changes. It offers flexibility and adaptability.

Enum names must start with a Capital letter.

New Enum Dialog

You can add Enums using the button on the screen’s right side area.

Type a capitalized name, click the green checkmark, or hit the “enter” key.

To add values to an Enum, select it and click “add value”. You can continue adding values by hitting the “enter” key after each one.
Enum values can begin with either a capital or non-capital letter.

To rearrange Enum values, drag and drop to a new position.

Importing Enums

Use Internal to import Enums from the current App.

Use External to import from dependent apps.  These are Apps added to the Dependencies section.

Fields

To add a field, select the entity and click the ‘+New field’ button.

Type the new field name in the text box. Then, hit the ‘Enter’ key if you want to add another field, hit the ESC key to cancel, or click on the green check mark button to finish.

By default, fields are of the String type; this is a text field, limited in size unless the Lob option is used; see fields’ purpose below.

Click on the field type to change the type.  Start typing to search for the required type.

Click on the type to change it.

Search for the type and select it.

The field type can be changed from the right-side menu once the field is selected.

Search for type on the side menu.

Click on the three dots (…) to access a more powerful tool for searching for a type.

Filter results by type name using the search box above, or use the drop-down to search by type’s grouping or origin.

The grouping includes Basic Types, Entities, Enums, and Types defined elsewhere in the current App or any library or App it references.

Note: other entities can be searched for when searching for a type. When another entity is selected for a field type, a reference to this entity is created. Below, you can see other ways to associate entities by reference.

Note: When adding multiple fields using the ‘enter’ key after each field, the type selected for any field becomes the default for subsequent fields until the type changes. When stopping multiple field entries using the ‘Esc’ key, The default type becomes String again.

Purpose

Select a field to highlight it, then select the Purpose drop-down on the right-side menu.

Field purpose selection.

Normal Field

Most Fields have no particular purpose. There is no need to set a purpose in such a case.

Id

This is similar to a unique identification number for an entity’s instance. Every entity should have this field, which can be inherited from a Super Entity. See below.

In Wizzdi Cloud, an ID is a String or a long. You can designate any field as an ID field, but only one can be designated as such. You can set the field purpose as an ID by selecting it from the right-side menu or using the “id” designated name.

Password

The password is stored in an encrypted format within the password field, ensuring it remains secure and inaccessible. This encryption applies when any entity, such as a User entity, is retrieved by a front-end client, and the password field is included in the retrieval. Consequently, the encrypted password cannot be deciphered or used to infer the original password. Furthermore, even if the application operates outside the Wizzdi cloud environment and the database is directly accessed, the encryption safeguards the passwords against any attempts to deduce them.

The type of a Password field must be a String.

LOB

A LOB (Large Object) field is designed to store substantial amounts of text, significantly surpassing the capacity of standard text fields, which typically cap at a few hundred characters. This makes LOB fields ideal for accommodating large documents, extensive descriptions, or any other form of data that requires more space than what is offered by conventional text fields. The LOB purpose applies only to String-type fields.

Creation Date

The system automatically records the creation date for any newly created instance when a field is designated as the OffSetDateTime type, and its purpose is configured as a Creation Date. 

Update Date

The system automatically records the last update date for any instance when a field is designated as the OffSetDateTime type, and its purpose is configured as an Update Date.

Note: You must ensure the purpose aligns with the field type, as this isn’t done automatically.

Field Ordering

Dragging a field to a new position

To rearrange an entity’s fields, click on each one and drag it up or down to the desired position.

Entity Relationships

In Wizzdi Cloud’s architecture, entities can be linked using different association types, resulting in diverse relationships and data mappings. Specifically, the available association types are:

One-to-Many

A one-to-many relationship between entities occurs when a single record in one entity (often referred to as the “parent”) can be associated with multiple records in another entity (referred to as the “children”). This type of relationship is commonly used to model scenarios where an entity needs to be linked to multiple instances of another entity. For example, in a database modeling a library system, a single Author entity might have a one-to-many relationship with a Book entity, indicating that one author can write multiple books. This relationship is typically implemented in databases by adding a field in the child entity that stores the reference to the parent entity’s identifier, establishing a clear link between each child and its parent.

Many-to-One

A many-to-one relationship between entities is the inverse of a one-to-many relationship, where multiple records in one entity (the “children”) are associated with a single record in another entity (the “parent”). This type of relationship is commonly utilized to represent scenarios where several instances of one entity are linked to a single instance of another entity. For example, in a company’s departmental structure database, multiple Employee entities (children) could have a many-to-one relationship with a Department entity (parent), meaning that many employees belong to one department. This relationship is typically facilitated by including a field in the child entity (Employee) that references the parent entity (Department), thus establishing a connection from many children to one parent.

Many-to-Many

A many-to-many relationship between entities occurs when multiple records in one entity can be associated with multiple records in another entity. This relationship type represents complex scenarios without a simple one-to-many correspondence between entities. For example, in a university system, a student entity might have a many-to-many relationship with a course entity, indicating that each student can enroll in multiple courses, and a course may include multiple students. A connection entity is typically used to implement this relationship in a system. This entity contains references to the two entities it connects, effectively linking multiple records from both entities and enabling the many-to-many association.

Examples

In the diagram below, we have two entities, City and State.

Although a City may reside in only one State, multiple Cities can belong to the same State. This creates a ‘Many-to-One’ relationship from the City perspective, meaning many Cities belong to the same State. However, from the viewpoint of the State entity, it’s ‘One-to-Many’ — one State is linked to many Cities. When defining such relationships, it’s important to establish the association from the ‘many’ side. Therefore, it’s necessary to include a ‘state‘ field within the City entity. Here’s how we can achieve this:

One-to-Many

Click on the one-sided entity, which in this example is the Country. We start with the ‘one’ side, but as you will see, the ‘many’ side holds the definition.

Drag the small circle onto the name of the other entity, in this case, the State entity. Release it when the pointer is over the other entity’s name.

Drag and release from the id field.

The state entity now has a field named country to indicate the connection’s ownership. A list of State instances has also been added to the Country entity.

When a one-to-one relationship is needed, create a many-to-one relationship instead.

Alternatively, it is possible to create the relationship using the Arrow button.

The entity-relationship tool

Click on the 90-degree bent arrow to open an entity search dialog. This should be done on the many-to-one side entity.

Search for the one-to-many side entity, and click on the selected entity in the above image, the Student entity.

In the many-to-one entity, a new student field is created. in the one-to-many side entity, a List of StudentTeacherToStudents is created.

This field facilitates more flexible joins when using the Custom Query tool. When this entity is retrieved, the list is never populated. The opposite approach is considered inefficient.

Many-To-Many

Consider the following entity diagram.

A simplified teacher and student diagram

This diagram illustrates three entities: Student, Teacher, and Subject. A Many-to-Many relationship is formed when a single teacher instructs multiple students, and a student may receive guidance from multiple teachers. In Wizzdi Cloud, you can establish a many-to-many relationship between entities by dragging the id field circle of one entity onto the id field of the other. Drag the small circle of the id field of the first entity (Teacher) and release it over the id field of the other entity (Student) when it becomes selected.

Release when the second entity id field is selected.

A new connection entity is generated.

A connection entity is automatically generated when you create a many-to-many relationship between two entities. However, if you prefer, you can create this entity manually and link it to both associated entities as the ‘One’ side. It’s important to note that this connection entity is a primary participant in the schema, not a secondary one. For instance, the absence of a field serving the ‘id’ purpose is indicated by a yellow flag above it.

A common way to improve the information about a connection is by adding extra fields describing the nature or features of the relationship. For example, when arranging a class, it would be helpful to include fields that indicate the day of the week, start time, and end time of the class. So, let’s add these fields to enhance the information about the class. We have already added an entity called subject, which can be dragged (from the id circle) onto the connection entity head to include the Subject in the connection.

Remove/Edit Relationship

When hovering over a relationship line, the line becomes emphasized. Click on the line to get a menu for deleting or hiding the line.

If you delete a relationship line, the fields linked on either end of the line will also be deleted.

Hiding lines can improve view clarity by reducing overlaps.

To show a hidden relationship line, access the field on the many-to-one entity and use the available menu to make the relationship visible.

Indexes

Indexes can significantly enhance query performance in a database by facilitating faster search operations. While it’s common practice to define indexes on frequently queried fields to optimize performance explicitly, it’s not required to manually index fields that are used to associate the Many-Side entity with another entity. The underlying database engine automatically indexes these fields.

Setting an Index on an Entity

Indexes are attributes of an Entity, and multiple indexes can be added. They can enforce uniqueness and may also be composite. Composite indexes are beneficial for data requiring multi-level sorting.

To set an index, select an entity and click ‘manage indexes’:

Manage indexes

When creating an index, you can designate it as unique. A field indexed as unique will ensure that no two entity instances have the same value in the field associated with the index. Adding a duplicate value to such a field at runtime will result in a runtime error.

Add entity fields to the index.

To create a composite index, you can add multiple fields. Adjust the sequence of these fields by dragging them, as the order can be crucial for querying and sorting operations.

Consider this example involving a composite index:

In an e-commerce application, purchases are tracked in a database, each with fields such as ‘date‘ and ‘totalCost.’

If you want to retrieve all purchases between Date A and Date B and within a cost range of X to Y, a composite index encompassing both ‘date‘ and ‘totalCost‘ can enhance the query’s performance. If questions frequently specify a specific date with a range of costs, then ‘date‘ should be the first field in the index, followed by ‘totalCost.’

Also, if the primary requirement is to sort the results by ‘date’ and then by ‘totalCost,’ then the ‘date’ field should precede the ‘totalCost’ field in the index.

Additionally, if there’s often a need to query just based on the ‘date‘ without specifying ‘totalCost,’ having ‘date’ as the first field in the composite index would also be beneficial, as databases can effectively use the index’s “prefix” for such queries.

Diagrams

Wizzdi Cloud supports multiple diagrams for large domain models.

Click “+” in the bottom left corner to add a new diagram.

Diagram Name Context Menu (right click)

Access the context menu by right-clicking on the diagram name to rename or delete a diagram.

The context menu is active only for the currently selected diagram.

Rename an Entity Diagram

Rename a diagram

Deleting an Entity Diagram

You can permanently delete the selected diagram from the context menu. This action is irreversible and cannot be undone.

Entities and Enums created in the diagram persist and can be imported into a new diagram.

Closing an Entity Diagram

You can close a diagram from #2 here.

When a diagram is closed, it can be reopened from the Add Diagram button.

When a diagram becomes too large, you can create a new one and transfer or duplicate some entity shapes onto the new diagram. However, note that only the entity’s delegate on the diagram will be copied, not the entity itself. This makes it easy to divide large diagrams into smaller ones.

To connect entities on separate diagrams, you must first move or copy one of the entities to the diagram where the other entity is located. After the entities are connected, you may remove one of the entity shapes from one of the diagrams to simplify it.

Moving, removing, and copying entity shapes can be done from the three-dot menu on the entity shape.

The post Domain Model first appeared on wizzdi.

Consumed APIs refer to the specific definitions of external services offered by vendors such as Google, SendGrid, and WhatsApp. These APIs enable the integration and access of their services directly from your applications. Additionally, consumed APIs facilitate the interconnection of various applications on the Wizzdi cloud, utilizing the principles of Service-Oriented Architecture (SOA).

Consumed APIs can be used to:

• Broaden Functional Scope: By integrating with external services, your app can extend its capabilities without building every feature from scratch.
• Streamline Processes: Utilizing pre-existing and well-established services like SendGrid ensures that specific processes, such as email delivery, are handled efficiently.

How to

Consumed APIs can be defined in two ways:

• OpenAPI Import: Most service providers provide definitions of OpenAPI (previously known as Swagger). These documents present a structured explanation of each of the API’s endpoints, responses, request formats, and other essential details. Wizzdi Cloud streamlines the import process of these files, automating the setup of the used API endpoints. This helps save time and guarantees that your backend conforms to the recommended standards and constructions of the external service.
• Manual Definition: If an OpenAPI file is unavailable, Wizzdi Cloud allows you to manually set up and define the consumed API endpoints. This must be done to match the documentation of the said API accurately.

The Consumed APIs section in Wizzdi Cloud serves as a bridge, connecting your backend to the broader ecosystem of web services. Whether you plug in manually or import an OpenAPI specification, this integration ensures your application remains versatile, dynamic, and capable of leveraging the best of what the digital world offers.

 

Open API

Select Consumed Apis from the left side menu.

Select the MANAGE option; two options are presented; use the pointer to see and select an option.

This menu offers two options: manually adding an endpoint or importing an OpenAPI file. However, the former should be avoided if the latter is available.

This is the top option; select it, and you should see this dialog.

Import from a URL

• If an OpenAPI JSON file URL is available, paste it into the top text box and click ‘Save Changes.’ For instance, we will use the URL from OpenAPI’s GitHub account:

https://raw.githubusercontent.com/OAI/OpenAPI-Specification/main/examples/v3.0/link-example.json

Import from a File.

Sometimes, if a URL is not provided, you can directly upload the API definition JSON/YAML file into the system. An example file is available here.

After a short while, you should see the following screen

Each API, whether imported or manually built, appears as one line.

Click on Manage to view the imported endpoints, including their type, input objects, and parameters. You should see a screen like the one :

API endpoints are specific URLs that software clients (web apps, mobile apps, other systems) use to request specific actions or data. Think of them like particular addresses within a city (the API), where each address offers a different service or information. They are usually accessed using methods like “GET” (retrieve data) or “POST” (submit data and receive data).

Click on EndPoints To Access the API endpoints.

You should see a screen similar to this one:

Refraining from modifying imported APIs is crucial, as it represents a binding agreement between the provider and any system using their services.

Manual definition

Click the ‘ADD API +’ button to add an API manually.

The new API dialog appears.

Update the following mandatory fields:

• Name: The name should start with a capital letter.
• Package Name Suffix: This should be the suffix used for the package of this API and can be any valid part of a Java package name, such as the API name.
• Base Path: The API owner must provide the base path, which cannot be modified arbitrarily. For instance, the base path for Apps in the Wizzdi Customers’ cluster is:
• https://[app-name].[user].[workspace-name].cluster.wizzdi.com/ 
• Description: Describes the API. This field is mandatory and cannot be left blank.
• Theme Color: Select a color for the API icon. This field cannot be left empty.

Endpoints

Select the endpoints menu option and then click on Add Endpoint:

Once you click on +ADD ENDPOINT, a dialog similar to this appears:

Endpoint Fields

Endpoint: this is the unique definition of the ‘address’ of the endpoint, for example,/api/ActiveOnCall/createActiveOnCall 
When defining an external service’s endpoints, the definition must match the external service behavior.

Name: This is the name assigned to the endpoint method. It must start with a non-capital letter and conform to Java method naming conventions.

Method: Select one of the available options matching the required method as documented in the external (consumed) API. See here.

Description: This is for internal documentation of the endpoint.

Tags: Endpoints within an API can be categorized using multiple labels known as tags. Generally, a tag represents a collection of APIs with a common theme or function. An endpoint may be associated with several tags, facilitating better organization and more straightforward navigation of related API functions. When adding a tag to an endpoint, you can use an existing tag or add a new one. Tags are case-insensitive.

When the App runs, regardless of location, the Swagger interface can access the API; below is a sample screen capture of the Swagger interface of a set of endpoints under a single tag, WeeklyTime.

Endpoint Management

An endpoint is displayed under all of the associated tags in a similar way to Swagger:

Use the pencil icon to edit the fields above or click on the arrow down  to define other properties of the endpoint.

Once the arrow-down is clicked, a dialog like this is opened:

This dialog manually defines the endpoint to match the consumed API details fully.

We have selected to edit the login endpoint. Our imaginary external service (the consumed API) uses basic authentication, and the username and password need to be defined in a Request rather than in the endpoint headers. Consequently, our method type should be POST.

A POST method requires a Request  (sometimes called a Body).

The Request object

Select the ‘select’ menu for the Request object:

Define a request object

When clicking on Select, the following options are available:

Select Existing: This option allows you to reuse objects you have already defined elsewhere in the app or dependent apps. In the current version of Wizzdi Cloud, when such an object is referenced. One should not change it.

When Select Existing is selected, a dialog like this one appears. Use the Search text box to find the object you need.

Create Custom: Use the tools described below to build a new object.

Define the Class name for the new Object; it should start with a capital letter.

 Click on the newly created Object to view it.

Expand to view the current object structure.

Optionally, Click the pencil to edit the Object properties, the name, and the description. 

Click on the plus icon to add a property to the Request Object.

Click the [+] button to add a new property.

The Create Property Dialog

The property name should be a noncapital word.

The Description is for documentation purposes.

To search for a Type, you can start typing its name in the Type field and select it from the list that appears. Alternatively, click the Type field to open a new Type creation dialog. You can also click on the three dots button to open a more detailed type search dialog.

Import JSON: You can paste a JSON object to create a new object. This useful option lets you define the JSON structure without using the Create Custom option. Additionally, it can be easier for some users to type out the JSON structure directly.

We will first use Import JSON  to define the Person Object (as an example).

• When the Import JSON dialog is displayed, fill in the required data here.

•  Now, we have the Request object defined as a Person. 
  
• 

Importing JSON is limited; only basic data types such as String, float, boolean, integer, and long can be used.

Importing JSON Schema is not supported.

Building a Complex Object 

Click on Select at the right of the request object, then Select the Create Custom option.

Building a custom object.

The following dialog allows a selection of an existing Object or the creation of a new one.

0

Click on the Type text box to access the ‘Create Custom Object’ button. Click on it to show the ‘Create Custom Object’ dialog.

Define a name for the object. The name should start with a capital letter.

Save the new custom object

Save the Request Object using the created Family Create

Once the object is defined, we may populate it while editing the request object.

To modify the Object name and description, click the pencil icon on the right.

To expand the Request Object for editing, click on the left-side arrow marked in yellow.

Click on the [+] to create a new property.

Create Property

Property names should start with a lowercase character.

Property Type

There are three options here:

• Start typing and select an existing type.
• Click on the Type field to open the Type/Object creation dialog.

Click on the Type field to allow selection or creation.

When Create Custom Object is selected, type the new Object’s name, starting with a Capital letter. Then click on ‘Save Custom Object’.

Create a new Object.

Once a new Property Type has been defined, you can start defining new properties (fields) inside the newly defined Type/Object.

The new Object has no fields initially. Use the [+] button to add properties to the new Object, including nested objects and Lists/Maps.

Lists and Maps

Lists and Maps are often required when implementing consumed or exposed API endpoints. They can be nested: a List of Lists or Maps containing Lists. Nesting is supported to any required depth.

Note:
Type safety is a core principle in Wizzdi Cloud, ensuring that data structures, including Lists and Maps, enforce consistency of element types

Lists

If the endpoint you’re using requires an array of properties, follow these steps:

• Click on the  icon.
• Select the  button.
• In the Create Property menu, choose List as the type. Start typing List and select the option below.

Selecting the List type

• Once the List is selected, the following dialog appears:

Select the inner type of a list

• Click on the Type field (marked in yellow) to perform one of the following options:
  1. Start typing the name for the inner type.
  2. Click on the three dots button to open an expanded dialog for searching for a type.
  3. Select Create Custom Object to create a new Object.
• For option 3, see the subsequent steps:
  • Create a new Object (Custom Type)

Create a new Custom Type (Object) for the List.

• Once the inner Custom Type (Object) is created, the List inner type changes:

The List inner type changed to <FamilyMember>

Maps

A map is a data structure constructed from a list of entries containing a key and a value. The key is used to retrieve the value efficiently.

Key and Value can be Objects, including Lists or Maps. Contained Maps or Lists are similarly defined.

Note: Although rare, there are instances where such a data structure is used in API endpoints.

To create a property of a Map type, proceed as follows:

• Start typing map in the Create Property dialog and select the Map type from the list below.

Create a property of Map type.

• The map is shown with the generic designation of <K, V>, where K stands for key and V stands for value.

• Select the data type by typing, using the three dots menu, or creating a new type by clicking in the type text box. You can also use List or Map as nested types.
• 

A String as a Key and a List of AppUser as a value.

• In the above image, the final type of the Map is displayed in 1.
• The type of the Key is displayed in 2.
• The type of the Value is displayed in 3.
• The value’s inner type (a List) is displayed in 4.

When selecting the Type as a List or a Map, a text box for the List type and two text boxes for a Map will open.

In the image above, 2 and 3 were opened when Map was selected. Then, when the map value’s type was changed to List, 4 was opened to define the list’s type.

Authentication

When defining consumed API, we must define how API access is authenticated. We have two options:

• Basic Authentication: This method requires sending a username and password with each API request. The credentials are encoded and passed in the HTTP request’s header. It’s simple but less secure and is often used for less complex or internal systems.
• Token-Based Authentication: This method uses a token for access instead of credentials. Users authenticate once to receive a token, which is then used for subsequent requests. It’s more secure and scalable, suitable for modern web and mobile applications.

Note: when dealing with consumed (external) API, the authentication definitions should match the external API (consumed) definitions.

Authentication Setup for consumed API

Basic Authentication 

This is the default setup. There is nothing to set. Add authentication parameters following the external/consumed API documentation when defining each secured endpoint. These parameters are automatically defined if an OpenAPI document is available for import.

Token Based Authentication

In token-based authentication, the login endpoint (sign-in) retrieves a token. It is defined as any other endpoint (see login example above) and returns a token. The path and parameters of this endpoint are usually documented in the external service documentation.

The retrieved token is usually automatically sent with any subsequent endpoint call. The consumed API interface provides a way to define this behavior following the consumed API definitions.

To set the common location where the token will be sent in every subsequent call to the API’s endpoints:

In the above dialog, every endpoint call is amended under the hood, with the token obtained in the login endpoint using a header parameter named authenticationKey.

Consumed APIs in Multiple Apps

Leveraging Service-Oriented Architecture for Enhanced System Interconnectivity

Overview:

Service-Oriented Architecture (SOA) emphasizes building easily reusable and interchangeable software components. With the rise of microservices and distributed architectures, SOA’s principles have gained significant traction. In this context, Wizzdi Cloud offers a unique advantage by allowing one app to interact with another seamlessly.

1. Consumed APIs in an SOA Ecosystem:

• OpenAPI for Inter-App Communication: Consumed APIs are not restricted to external services like Gmail or SendGrid. When working within the Wizzdi Cloud ecosystem, one app can directly import the OpenAPI of another Wizzdi Cloud app. This paves the way for fluid data exchange and service usage between different apps, fostering a cohesive network of interconnected applications.
• Standardization with OpenAPI: By leveraging the OpenAPI specification, Wizzdi Cloud ensures that app-to-app communication adheres to a recognized and consistent format. This standardization reduces integration overhead and potential discrepancies, allowing for a smoother interoperability experience.
• Multiple Options for Reusability:
  1. Adding Dependencies:
     • ***************************
  2. Integration without SOA:
     • Wizzdi Cloud allows users to add dependencies to their apps. This means that users can incorporate additional functionalities or components into their applications. These components can be self-developed or sourced from the Wizzdi or other Market Places.
     • When components are added this way, the original backend of the app is merged with the backend of the external elements. This creates a unified, singular backend system.
     • As a result of this merging, the database created is a collective of entities (or pieces of data) from all the incorporated components. This implies a more integrated data structure.
     • These components’ services (or functionalities) communicate internally in this approach. There isn’t a need for external calls or connections; everything is managed within the unified system.
  3. Integration with SOA:
     • SOA, or Service-Oriented Architecture, is a design principle where services (functionalities) are made available to other parts of an organization through APIs (Application Programming Interfaces).
     • In the context of Wizzdi Cloud, when using an SOA approach, each service or component becomes a separate instance in the Wizzdi Customer’s Cluster. This means each service operates independently and is like its own mini-application. You have the option to deploy the apps either on-premise or on a different cloud service.
     • The integration or communication between these services happens purely through their respective APIs. Instead of having a single, merged backend, each service communicates externally with other services.

   

  Summary:

  • Without SOA: Consider blending ingredients to make a single smoothie. You can’t distinguish the individual components; they are fully integrated. This is how Wizzdi Cloud allows apps and their dependencies to merge.
  • With SOA: Imagine a tray of different cups with a distinct beverage. You must sip from each cup separately if you want a taste of two or more. They remain distinct; it’s an external process if you want them to interact. This represents the separate instances communicating through APIs in Wizzdi’s SOA approach.

  These two approaches would depend on the project’s specific needs and design preferences. Some may prefer the seamless integration of the non-SOA method, while others might find the modular and independent nature of the SOA approach more suitable.

2. Benefits of SOA Integration in Wizzdi Cloud:

• Reusable Components: Embracing SOA principles means you can design an app component once and then deploy and utilize it across multiple applications. This not only reduces redundant effort but also ensures consistency across projects.***********
• Scalability & Flexibility: As your system grows, you can easily add or modify new services without disrupting the entire application ecosystem.
• Optimized Maintenance & Upgrades: With distinct apps handling specific services, updating or patching one service doesn’t necessitate taking down the entire system. This modular approach streamlines maintenance tasks and minimizes downtime.

3. OpenAPI Publishing in Wizzdi Cloud:

Every app built on Wizzdi Cloud automatically publishes its exposed APIs via an OpenAPI document. This self-documenting feature means that any other app, within or outside the Wizzdi Cloud environment, can access and understand the functionalities. It acts as an open invitation, encouraging other systems to leverage the services provided by the app.

In summary, Wizzdi Cloud’s support for SOA principles and its inherent capabilities around Consumed APIs position it as a robust platform for creating intricate, interconnected software ecosystems. Whether you’re aiming for a vast web of interlinked applications or want two apps to share resources, Wizzdi Cloud provides the tools and frameworks to make it happen effortlessly.

The post Consumed APIs first appeared on wizzdi.

Wizzdi Cloud strives to simplify the backend development process by automating foundational aspects, like creating repositories and generating code for CRUD operations on entities. However, real-world applications often demand more granular control and nuanced data interactions. Recognizing this need, Wizzdi Cloud offers advanced tools such as the custom query builder.

 Automated Entity Management

• Instant Repository & Service Generation: As you sculpt entities within Wizzdi Cloud, the system recognizes these entities and instantaneously crafts the requisite data repositories and accompanying services to facilitate basic CRUD operations.
• Smart Data Retrieval: Wizzdi Cloud is designed with an innate understanding of entity relationships. For instance, when querying for an entity related to another entity, the system automatically fetches relevant connected data. This feature ensures that data remains contextually rich and relevant. Using the authors and books example, when books are queried, their corresponding author is nested within the retrieved data, providing comprehensive insights without additional requests. This happens only when you retrieve the ‘many’ side of the relation, in this case, the Book. When an Author is retrieved, no book list is populated.

Custom Query Builder

• Beyond Basic CRUD: While automated CRUD operations suffice for many scenarios, there are times when the default isn’t enough. Whether it’s complex filtering, advanced aggregations, or specific data transformations, there are myriad cases where a more hands-on approach to data access is warranted.
• Intuitive Interface: The custom query builder is designed with user-friendliness in mind. It provides a visual platform to define specific data retrieval conditions, ensuring you get the exact slice of data you need in your desired format.
• Integrated Code & Repository Creation: As with entity creation, Wizzdi Cloud takes over the heavy lifting once you design a custom query. It generates the necessary data repository structures and crafts the service code, ensuring that your custom queries are not just designs but instantly actionable components of your backend.

How To

General

A custom query is usually connected to an API endpoint or is called from a Flow. 

These associations are defined using the user interface, if you are interested, like all other elements created in Wizzdi Cloud, and regardless of the deployment method, a custom query becomes generated code behind the scenes. Some of us, sometimes, may want to look at the code, change it, or enhance it. Otherwise, it is just interesting to know.

When we create a custom query, we use the domain model. Custom Queries provide a way to retrieve data beyond the data retrieval provided by the exposed CRUD APIs.

Like the data retrieval services created by the system, data is efficiently fetched using the system’s database engine.

The process of creating a query is usually along these lines:

• Define the entities participating in the query; these must be entities from our project and entities from referenced projects, be it from other workspaces or marketplaces.
• Define the data structure passed to the query; usually, filtering parameters are passed this way. This is called the Request.
• Define the data structure the query returns; this is called the Response. Besides exceptional cases, most queries return a list of the response object type.
• Define the conditions narrowing the result set; for example, fetch all Students studying mathematics.
• Define optional sorting.
• Define optional grouping. Grouping is an essential concept in queries; for example, calculate the number of students in each class passing minimum average exam result.

The User Interface

Add Query: To add a new custom query with name and description fields, the name must conform to Java class names.

Manage: edit a query after it is created.

Root and Connections (joins):  here, we define what are the entities participating in the query.

Root Entity: In query construction, the root entity is the primary Entity from which the query starts. The central table in your query emanates from all paths (joins) to related tables. Select it by right-clicking on a space on the left side of the screen.

Searching for a root entity.

Adding entities

Why we need to include other entities via cascaded joins from the root entity:

1. Response Composition: Include related data from different entities in a single query response.
2. Condition Application: Apply conditions involving fields from multiple entities.
3. Result Sorting: Use fields from included entities to sort query results.
4. Data Grouping: Group data by fields from multiple entities in aggregate functions.

Joins are essential when data is normalized across multiple entities, requiring compilation or comparison of information from those entities.

We can use reference fields on the root item to add more entities. (in the image above, we have the Teacher and MainSubject)

Right-click on a reference field (if its type is another entity) and select Join.

You can continue adding more entities from the available reference fields on any entity on the diagram.

Note: When one-to-many relations relate entities, we normally find a field of the one side in the many-side entity. For example, a Child entity may have a Mother field in the underlying database, but there is no Children field in the Mother entity.

However, Wizzdi Cloud adds such a List to the one-side entity. This list is never populated, as it can be infinite in size. However, it is readily used in joins; for example, instead of using the TeacherToMainSubject entity as root, use ‘real’ references to add both Teacher and MainSubject entities to the diagram; we can start with either Teacher or MainSubject like this:

The request

Every query must define a Request object. This object provides the query with the required parameters affecting the result set.

Define a new request by right-clicking on the right side empty area.

Select Request from the right-side top menu, then right-click to define a request object.

The request object includes mandatory fields to control the size of the result set: pageSize and currentPage.

Click the right-facing small arrow to open the Request.

Minimal Request Object

Adding fields

The request object can include nested objects. To define a new object, click the Object button.

Using the respective ‘+’ sign, you can keep adding fields at the correct level; when adding a property, you can use the new types you have defined while creating Objects.

The fields from the Request object are usually used in conditions or the response object.

The Response

Available options when building a response object:

• Create a property; the property has a name and a data source.
• Create an Object accommodating a more complex structure in the response.

We can now select the data source for the subjectName property.

While setting the data source for a property.

Using functions in conjunction with fields.

The post Custom Queries first appeared on wizzdi.

By Default, Wizzdi Cloud generates CRUD API endpoints.  To change this behavior, select Exposed API from the menu.

Select Settings 

Then, switch off the Auto Generation option. 

Importing an Open API API specifications

Wizzdi Cloud supports the import of Open API definitions from a URL or a file. In both cases, the definitions can be JSON-based or YAML-based.

Importing Open API specifications is the first step in the Contract First approach. Alternatively, the API endpoints can be manually defined.

Select manage at the bottom right corner of the Exposed Api section, then select the top option.

Import Open API definitions from the URL into the Exposed API.

Below is an example of an OpenAPI URL from another demo App deployed in Wizzdi Cloud Customer’s cluster, where Apps may run.

In such cases, the URL is https://[appname].[workspace].cluster.wizzdi.com/api/v3/api-docs
for example, https://publish16.avishay-s-workspace.cluster.wizzdi.com/api/v3/api-docs.

Paste the URL in the upper text box of the import OpenAPI dialog.

Here is the link

Hit the Save Changes button. After a while, you should see the endpoints in the exposed API view.

To import from a file, click Upload File and browse for a valid OpenAPI file on the local system.

The import can be executed as many times as required. Note that importing an existing endpoint will not change its signature.
Changing the EndPoint properties can be carried out by the built-in editor provided in Wizzdi Cloud.

One needs to scroll to see all imported endpoints.

Note: We can see the endpoints if we deploy the application now. However, the endpoints are not currently linked to any actual actions. Linking the endpoints to ‘real’ actions requires the following steps:

•  Infer the domain needed model from the endpoint definitions.
• Create the domain model entities, enums, and relationships.
• A Custom Query,  a Flow, or both for each endpoint.
• The imported API defines the request and response objects required in the Custom Queries and Flows.

Manually Creating a Custom Endpoint

In the exposed API section, click the ‘Manage’ button at the bottom left of the screen and access the Add Custom Endpoint option.

First, define the primary properties of the new endpoint

Legend

1. This is the endpoint name used when calling the API.
2. This is the name of the method created in the corresponding controller.
3. The Method of this endpoint, Wizzdi Cloud, supports the Post, Get, Put, and Delete methods.
4. The description of the endpoint for documentation purposes.
5. The Tags associated with the endpoint, Tags are used to group endpoints. Endpoints can be associated with multiple tags and displayed in the OpenAPI interface multiple times.
6. The list of tags associated with the endpoint. An endpoint must be associated with at least one tag.

The above dialog is also available when editing an endpoint.

Managing Exposed EndPoints.

Once the API is imported, endpoints are visible under the corresponding tags in the OpenAPI document.

This is also true for an API that is created manually.

To enable an endpoint in a web application or API to perform specific actions, it must be integrated with either a Flow or a CustomQuery. A Flow refers to a predefined sequence of operations or tasks the endpoint will trigger and execute. These operations could include data processing, database interaction, calling other services, or other flows. On the other hand, CustomQuery is a user-defined operation tailored for complex or specific data retrieval. It involves using the Wizzdi Cloud custom query visual tool. By linking an endpoint to a Flow or a CustomQuery, you define the exact functionality that the endpoint will offer, essentially ‘programming’ it to respond to client requests meaningfully.

To edit an endpoint, click on the small open triangle to the right of its available tools.

Endpoint primary properties

Click on the small pencil icon to access the endpoint’s primary properties.

To associate the endpoint with a tag, start typing the tag name; if the tag exists, you can use the + sign near the tag to associate it with the edited endpoint. The current version of Wizzdi Cloud doesn’t support multiple tags per endpoint.

If the tag does not exist, a button will appear, allowing you to add one and associate it with the edited endpoint.

Endpoint additional properties

Once the endpoint has been created, its other properties can be set. This includes the path, Header, and Query parameters.

Expand the view of the endpoint by clicking on the small arrow:

1. Path parameters

These are parameters embedded directly in the URL path to identify specific resources.

2. Headers Parameters.

These are metadata (key-value) or information included in the request headers but are not visible in the URL

3. Headers Parameters.

Adding Request object

The Request Object is essential in a POST method. It contains a JSON body from the client, which the server uses to retrieve, create, or update resources.

• Create a new object called FamilyCreate.  

•  Open the new object members editing by clicking on the two small arrows, first #1, then # 2 
• Proceed by clicking on the ‘+’ sign to add a member.
• Select Object here -> 
• In  the Object Creation dialog, Select the name -> Person 
• The default name for the created Person object is ‘person’; let’s use the ‘pencil’ icon to change it to Parent1 as below:
• 
• Let’s expand person1 using the small arrow to the left of its name and click on the ‘+’ sign to add two properties. A name and a birth date.
• 

Note: Adding these properties to the parent1  field in the request object changes the object Person. Other uses of the Person object are immediately affected.

• Let’s add a new parent2 field. At this time, the Person object is defined, and we will create a Property of the type Person.
• Click on the ‘+’ sign at the highest level of the Request object and select Property.  

Note: Please be cautious when selecting which ‘+’ sign you click on. In the image above, the upper ‘+’ adds fields to parent1, whereas the lower ‘+’ adds fields to the request object.

• Add the name parent2, then start typing ‘Perso’ in the Type field. When the previously defined Type becomes available, select it.
• Click on ‘Create Property’ to dismiss the dialog. 
• Once both parents are added, you should see:
• 
• Let’s add a List of children to the FamilyCreate object:
• 
• We have added a familyName to the request object. The final object is below:
• 

The post Exposed API first appeared on wizzdi.

Dependency management within Wizzdi Cloud ensures your application integrates seamlessly with other projects and artifacts. This facility allows for the incorporating and reusing of external resources, streamlining development by building upon existing components. Let’s explore this in more detail.

Adding Dependencies:

• Workspace Dependencies: You can incorporate components from other projects within your current workspace. This is especially helpful if you have multiple interrelated projects and want to leverage functionalities or data structures from one project in another.
• My Market Place Integration: Beyond your workspace, “My Market Place” is a repository to import external projects and artifacts. Once imported, these become available across all your workspaces, making integrating and reusing established components in various apps easy.

Referencing and Utilization:

• Domain Model Integration: You can refer to or integrate entities from other domain models with the defined dependencies. This facilitates a modular approach, where specific domain components can be standardized and reused across multiple projects.
• Custom Queries and APIs: Dependencies aren’t limited to domain models. You can also reference and utilize custom queries and APIs from other projects, ensuring you don’t reinvent the wheel and maintain consistency in data access and manipulation.
• Business Flow Interactions: Business flows, which define your applications’ logic and operational flow, can also integrate functionalities from dependencies. This is particularly beneficial when standard operational patterns are established and must be replicated across applications.

Wizzdi Cloud’s dependency management is a modular and integrated application development cornerstone. Userd can ensure consistent, efficient, and integrated application functionalities across projects by defining and managing dependencies effectively.

Reusability

In Wizzdi Cloud’s no-code platform, modularity and reusability are core principles. This allows users to efficiently construct applications by leveraging components from multiple projects. Here’s how it works:

1. Project References: Within a user’s workspace, it’s possible to reference other projects directly from the current project or application. This is achieved through the “dependencies” menu option.
2. Workspace Reference: You can reference project components from other workspaces you can access. Workspace owners can invite other users to use their projects; access can be read-only, so invitees are blocked from changing them.
3. Marketplace Workspaces: Wizzdi Marketplace workspaces are available for users of Wizzdi Cloud. The ever-growing repository of solutions can be the starting point for a new project or form most of it. Marketplace apps can either be imported to one of your workspaces, or their elements can be referenced directly from the marketplace. These elements can be
4. Code access:  Including dependencies in your code is possible from private and public repositories, such as Maven Central. This allows your business logic (flows) to access the methods and public classes defined in the referenced code. But, it is essential to have a basic understanding of Java code and the services that the referenced code offers.

External Entities Integration

This section will provide a concrete example of how to reuse one app within another.

The External App

Here is the domain model for an app called Organization. It describes the organization’s structure, including its employees, branches, and addresses.

Here, we have added the Address model to the Organization App.

The dependent App

Here is a very simplified domain model for an e-commerce app seller entity where the Organization entity is set to be the Super Entity of a Seller.

Step By Step

Access the dependencies option from the left-side menu.

After clicking, you may encounter a view similar to this:

Click on ‘+ Add Dependency’ to add one,

Click on ‘Search Projects’   and start typing organization; once the Organization-model becomes visible, select it to make it accessible to your project. Once selected, all of the elements in this App are available to the dependent App. The external API the App exposes combines the Referenced App Apis and the Apis from the dependent App.

Using entities from an external App

Right-click on a space in the diagram and select Import->Entity->External  

Then, please search for the desired entity and add it to the diagram 

Once visible on the diagram, it can be used in two distinctive strategies: Inheritance and composition.

Inheritance

Select the circle above the Seller entity, drag it to the Organization entity, and then release it on its header.

Once released, the Seller entity includes the inherited fields from the Organization entity.

Two additional fields (not inherited) were added to the Seller entity.

Composition

Here, the Organization entity’s ID circle is dragged onto the Seller name, creating a one-to-many association where the Seller is the many- side.

The composition approach offers several benefits. Firstly, it ensures that unnecessary fields from the Organization are not incorporated into the Seller. This means that the Seller remains streamlined, containing only relevant data. Moreover, the composition method allows the Seller entity to encompass many external entities as fields. This adaptability allows for a more tailored and modular structure, accommodating a wide range of relationships and data sources without compromising the integrity or clarity of the Seller entity.

The post Dependencies first appeared on wizzdi.

Imported Apps

Components are used in Wizzdi Cloud when a different App is imported into the current App.

Apps can be imported from Wizzdi MarketPlace, your MarketPlaces, and your workspaces.

When an App is imported, it appears as a component in your app. Thus, you can always view its structure using the Wizzdi Cloud user interface.

Flexicore Run Times

In Wizzdi Cloud, when initiating a new application, users have a choice between two runtime environments: Spring Boot, a well-known framework, and its extension, FlexiCore Boot. FlexiCore boot has all the features of Spring, a Spring Boot with additional features.

Features

• Access Control:  Multi-tenancy, refined data, and API access control are often needed. FlexiCore Boot offers tools to address these requirements effectively.
• Modularity in Action: Rather than confining feature modifications to the development stage, FlexiCore Boot supports real-time component integration or removal. It accomplishes this by treating these components as active plugins. This dynamic nature has several benefits:
  • Integration: Enables the smooth addition or removal of components without a complete system reset.
  • Adaptability: As application requirements shift or grow, it’s possible to introduce new functions seamlessly.

Component Types

• Model Component:
  • Purpose: To define the domain model of the application.
  • Features:
    • Structures essential data entities and their interrelationships.
    • Dictates how data will be organized, preserved, and accessed.
    • Serves as the foundational framework for services, APIs, and business logic.
• Service Component:
  • Purpose: Handles nearly all functions outside of the domain model.
  • Features:
    • Manages both exposed and consumed APIs.
    • Supports custom queries and business flows, shaping the application’s interactions with its data and other systems.
• Module Component:
  • Purpose: Generates a usable module for integration into the FlexiCore Boot runtime.
  • Features:
    • Modular design for easy runtime integration.
    • Supports specific functionalities or features for modular addition or subtraction.
    • Facilitates scalability by allowing for the addition of new modules as needs change.

Considerations

While FlexiCore Boot offers dynamic modularity and refined access control, it does come with a consideration. Applications developed using FlexiCore Boot become dependent on the FlexiCore framework. This dependency contrasts with the more universally applicable Spring Boot framework. To ensure flexibility and to cater to varied requirements, Wizzdi Cloud provides support for both runtime environments, allowing users to choose the one that aligns best with their needs and plans.

FlexiCore Boot and Felxicore are open-source and available on GitHub. Binary artifacts are available on Maven Central.

The post Components first appeared on wizzdi.