Nothing Goes From Idea To Container Faster

Web Client Guide

Getting Started

realMethods is all about redefining DevOps Project Creation.

Unlike traditional code generators that are often single purpose and only generate a fraction of what a project needs, realMethods generates multi-tier applications. An application could be a traditional web app, RESTful APIs, or a set of server-less functions. The goal of realMethods is to to make application generation a seamless essential phase in any development process.

This document is a guide to using the browser based client to the realMethods platform. This client accesses most of the functionality available, while full access is granted to the API and CLI versions. Nonetheless, this version allows for the generation of a variety of applications using the current standard technology stacks. If it is necessary to enhance an existing technology stack or create and publish a new one, that capability is available in the API and CLI versions.

Initial Access


To initially access realMethods through either the Web App or the Command Line Interface (CLI):

For Community Edition:
You can Register a new User account or login using the default credentials of admin and letmin2 as the userId and password respectively.

For SaaS:
You must create a new user account by clicking the Subscribe button to purchase a subscription. Once completed you will be directed to register.

Once registration is successfully completed, a unique user token will be assigned and presented to you. You will need this token if using the Command Line Interface verion. This token can later be read from the User Input page.

Using the Control Panel

Clicking the chevron in the upper left-hand corner will reveal the control panel to view the options available to generating an application.

Templatized Teck Stack Pkgs (TTSP)

For the sake of this discussion, we will briefly state that a technology stack is an ideal whereby a software application leverages a well defined and understood set of distinct technologies. In practice, experience often shows the technologies in the stack are well known, most trusted, serve a well defined purpose, and co-exist well with others in the stack. Often a tech stack is an abstract concept, only effectively defined because an application “uses” each of the technologies. However, often a technology stack is “bundled” as a single deliverable whereby the bundle handles the stacking, integration, and delivery of the technologies in the stack.

realMethods concept of a Templatized Technology Stack Package (TTSP) improves on the tech stack concept, picking up where it leaves off. A TTSP not only includes all the concepts of a bundled tech stack, but includes the template-driven abstractions, features, components, and services of a specific kind of application. Template-driven is crucial to a TTSP because it is the tie between a tech stack and an entity model. Importantly, a TTSP accommodates the endless combination of technologies and application features with even a single business model.

Choosing a TTSP

Based on the target requirements of the resulting application, choose which TTSP best meets those requirements. The list shown in this document is likely not up to date. If you do not see a TTSP in realMethods realMethods run-time that adequately meet the application requirements, contact support@realmethods.com.

Creating a Technology Stack Package

If a suitable TTSP is not available, determine which of the available TTSPs is closest to the required application stack, and using the realMethods CLI, download that TTSP, make modifications as required, then upload the new TTSP as a single Zip file.

The following components of a TTSP should be understood.

techstackpackage.xml

This required XML file contains the overall description of the package itself. It is most useful for the sake of providing documentation as to what the package contains and the general intent of the TTSP’s components.

Note: If creating a TTSP, use frameworkpackage.xsd to validate the structure and content of a frameworkpackage.xml file. When uploading a TTSP to the platform, this XSD file will be used to validate the frameworkpackage.xml file. If it fails to validate, the upload will be cancelled and the attempted file deleted.

Click here to review the contents of a frameworkpackge.xml file

options.xml

This required XML file contains the global options for each application created regardless which TTSP is applied.
It contains general level options specific to any application such as the app name, author, app logo URL, GitHub parameters, etc.. This is the place to add an option to be applied to all applications being created. Adding options is encouraged, but be aware that removing options may impact how the application is created and how it behaves at run-time. The TTSPs realMethods includes often have more than one options.xml file found in a multiple sub-directory containing template files related to a specific framework or toolkit. For example, template files related to the Hibernate ORM framework require configuration input from the user, and these configuration parameters would be placed in the options.xml file also found in the sub-directory of the template files.

The support options types and the corresponding form field are as follows:
type=”input”, form field : “text”
type=”word”, form field : “password”
type=”select”, form field : “selection”, selections correlated to form field : “options”
type=”boolean”, form field : “checkbox”

Each option field can include the following fields:
modifiable : “true/false”
required : “true/false”
description : placeholder

Click here to review the contents of a options.xml file

mappings.properties

This required file contains the declarations as to where to output a created file. This provides the flexibility needed to separate where a template file is found as opposed to where its created output should be placed for the sake of coding convention, the build process, application deployment, etc…

Click here to review the contents of a sample mappings.properties file

Create a New App From a Model

If starting with a new idea without an existing application, this is the place to start. realMethods supports loading a model definition from an appropriately structured JSON file, or an XMI file containing standard UML.

realMethods installs with examples of supported models accessible from the Catalog option. Optionally, a newly loaded model can be saved to the Catalog for future reference.

Once a model is loaded, observe how t interpreted it. It is important to browse the tree control representation to ensure the intended model has been captured. realMethodssupports the models composed of containers, classes, attributes (long, double, string, date, time, etc..), associations (one-to-one, one-to-many, many-to-one, many-to-many), interfaces, and enumerated types.

Re-factoring From an Existing App

realMethods can deduce an existing application model from a JAR file of POJOs, a SQl script, or direct connect to a database’s schema. This feature means fundamental application migration can begin without having complete knowledge of the originating application. This includes migration cases that cover refactor, rewrite, and replatform. This means an existing app written in an older language on an obsolete platform can quickly have its core recreated using a more prevalent language using today’s popular technology stacks. This includes creating layers for the presentation, business, data, caching, and persistence.

Application Options

A TTSP can provide any number of options that are dynamically loaded when selected in the list of TTSPs. If you are unfamiliar with a TTSP, select each tab to see what fields need data applied. If realMethods will be directed to push the application files to GitHub, select the tab and apply the required fields including:

host (where is GitHub hosted)
repository (where on GitHub is the project to be pushed to)
username and password (to access the GitHub host securely)
tag (how to distinguish this project push)

Application Archive

Each time code is generated, all the generated files, along with the TTSP and model used, are archived. An archive can be downloaded as a single zip file by clicking the down arrow next to the listing.

Create the Application

Once a Technology Stack Package has been selected, an entity model has been provided, and application options have been reviewed, and application can now be created. Pay attention to the GitHub options if a push of the source code is required.

Once the application is created, you should verify it has been commited by checking out the Git Repo you designated. If you do not see any files, make sure you provided the correct Git parameters.

Next, if you assigned a CI platform, you can create a pipeline which should auto-read the generated config YAML file for that vendor. Using the Git repo the code resides in, the pipepline should build/test/deploy the application. Please refer to the CI vendor documentation for more details on this.

Close Menu