A Business Application Framework

RZO is a free and open business application framework that is:

• Mobile. Other business applications have mobility added on top of a much older legacy infrastructure. RZO has mobility as a core requirement from the beginning.
• Offline/Disconnected. RZO aims to work with offline/disconnected clients (mobile or otherwise) that synchronize once connection has been reestablished.
• Scalable. RZO is designed to scale from a small business with a sole proprietor to multinational enterprises with millions of customers as users.
• Hybrid Infrastructure. RZO runs in its entirety on a small laptop with a local DB and single server process and scales all the way up to containerized cloud infrastructure such as Kubernetes connected to database clusters.

RZO is a pure JavaScript based implementation. This allows the same code to be run on small devices and Web browsers as well as servers, virtual machines and container-based enterprise infrastructure. The data storage is provided by PostgreSQL on the server side(s) and CouchDB-compatible databases on the client side. The data backend aims to be fully compatible with the Couch Replication Protocol in order to synchronize with small devices in an offline/online mode as well as other PostgreSQL databases in a fully distributed / clustered database infrastructure.

Every change made to a record in RZO must be fully audited and version-controlled. This allows for offline/online replication to work properly and to resolve data conflicts that will inevitably occur with changes made while devices are offline. This also makes it possible for RZO to be considered for highly sensitive applications and industries such as Energy/Utilities, Pharmaceutical, Nuclear, Defense and Government.

Being a business application framework, RZO doesn't define or lock in specific business application objects or logic. The specific objects in the repository serve to illustrate common traits that are found in business applications such as Product Management, Procurement, Finance, Work Management, Human Resources, Inventory Management, Workforce Planning/Scheduling, etc. You are free to define, extend or modify your own objects. In fact, you are encouraged to publish and share your business application in the hopes that a full ecosystem of business objects, applications and functionality is created from which end-users can pick and choose.

A typical RZO application utilizes the following concepts found in the framework:

• Entity
• Field
• State
• Collection
• Row and ResultSet
• Persona
• Policy
• Source

An Entity describes something that is stored. It could be a 'thing' such as a user or customer, or it could be an 'action' such as a purchase or a work order. You can think of an Entity as a table in a database, and while that is true, it's not the full story, as you'll learn later on.

Each Entity consists of Fields. Fields describe attributes on the Entity, for example, the name, address and city for a person. While not quite the same, you can think of Fields as columns in a table.

RZO explicitly separates data and metadata: Entities and Fields describe the metadata for a business object: how many fields, their names and types of data it users such as text, numbers, dates, etc. State holds the actual data for a given Entity. For example, if the Entity for a "customer" describes it as having a Name, City and Last Order Date, then State holds an actual customer "Joe", "Houston" and "June 1". Perhaps it's easier to describe it this way: when a given server is being used to service 10,000 customers at a given moment, that server only has one (1) instance of the object "Entity: Customer", but 10,000 instances of the 'State' object. State is designed to be as small and simple as possible to conserve resources and make RZO scale easily. If you've dealt with extending or programming other business applications, you'll probably have to get used to the idea that Entities and Fields do not 'hold' or 'store' any data, they operate on State objects that hold data instead.

A Collection describes a list of Entities. You can think of a Collection as a database query. While that is how a Collection will be constructed when asked, it's more powerful than that. For example, Collections can dynamically adapt based on who is asking for the data. A list of pending work orders would change based on who those work orders are for: even though they both query the same collection, Charley sees WO101 and WO102, but Alice sees WO203 because they work in different geographic areas, or because Charley is a mechanic and Alice is a powerline inspector.

A Row is how data is passed around in RZO, both within the client or server, as well as in between the client and server. It is designed to be as lean as possible. In fact, it's a very thin wrapper around the standard JavaScript Object with the actual data being held in that JavaScript object. Row wraps several convenience and standardization methods around the standard JavaScript Object that handle things like 'undefined' vs. 'null', conversions to/from strings, etc. A ResultSet is an iterable list of Rows. In its simplest form, it's a JavaScript Array of Rows, but not all lists are equal: for example, small mobile devices are better served with 'paging' lists, to conserve memory and reduce 'stickiness' when users ask for a lot of data. ResultSet manages the complications of all that.

A Persona encapsulates the job position and authorization of an individual that's logged into RZO at any given time. A machine shop mechanic needs different access and data than a VP of Finance to do their daily tasks. RZO separates the user login process from their Persona: authentication is best handled by Identity Providers using OpenID/SAML outside of RZO, either in-house or hosted. Once authenticated, the user's authorization profile - what they are allowed to see and do in RZO - is managed via Personas. A user can have (or "be") multiple Personas, but only one Persona is active at a time.

A Policy controls what data users have access to, and what they are allowed to do with that data in terms of modifications. Just like Collections, Policies are dynamic. For example, a Policy that controls access to work orders can allow Charley to view and edit WO101, but only view WO203, because the Policy that's assigned to his 'Mechanic' Persona prohibits editing the 'Inspection' work order WO203.

RZO allows data to come from various places at the same time. For example, a mobile client tool should be able to pull data from a live server that can't be cached locally for storage / performance reasons as well as work with data from its local storage when in offline mode. A Source abstracts the actual interaction with a server or backend so that Collections don't need to know the underlying protocol to obtain their data.

The choice to go with a strong copy-left license wasn't made lightly. It is fully understood that a business application framework will not work without an ecosystem of software, consulting and implementation services companies that need to get their work paid for. GPLv3 can be a controversial subject for those outfits and sometimes their customers because of the copy-left aspect. In layman's terms, here's what's intended to be possible and not possible under that license. PLEASE NOTE that the following list does not supercede, alter or change the license as specified in LICENSE. Always follow LICENSE.

• Extensions or modifications that, for example, implement business logic for you (if you are the end-user) or your customer (if you are a service provider) do not have to be made public (copy-left) AS LONG AS they remain both private to and owned by the end-user.
• If you are a service-provider and wish to re-use/resell/license (or any other means of transferring) code extensions or modifications made for customer A, or made in-house without a customer, to customer B, you MUST open-source (i.e. copy-left) those changes in accordance with LICENSE.
• A common value proposition of consulting companies to their customers is to state they have 'prebuilt', or 'best practice', or 'starting kits' for IT implementations. With RZO, those would be open-source. The value proposition would therefore shift from having a proprietary 'mouse trap' to their expertise in how to implement, support and shepherd those changes to the end-user.

RZO is a non-democratic and completely apolitical project. You are free to suggest changes to the code or the project itself, but the following rules apply.

• Do not make any comments, remarks and/or suggestions that are social, political, religious or non-technical.
• Do not describe yourself with any form of identity other than your name and (optionally) your physical location: city, state/province, country.
• Do not display your race, age, gender, religion, pronouns, sexual orientation or any other identifying trait other than described above.
• Do not make non-technical comments, remarks or suggestions that utilize or imply concepts that include (but are not limited to) "sensitivity", "inclusivity", "environmental", "social", "society", "diversity", "equity", "equality", "concience", "rightness", "wrongful", "historical", "sexuality", "identity", "gender", "ancestry" or any derivative of those concepts.
• Do not make comments, remarks or suggestions that try to circumvent the terms used above but still convey the same sentiments.
• Any and all suggested changes can be rejected or ignored without specifying any reason for doing so.
• There is no challenge, escalation or appeal process for rejections.
• If your suggested change was rejected without any reason provided, your change likely broke one of the rules stated in this list.