The One Network SDK processes several different "flavors" of the model. There are a number of models that are part of the Core Platform. These models are common models, called Master Data Models, every application will need, such as user, group, partner, role, etc.
The second type of model we see is application models. These are models you create specifically for your project's requirements.
The third type of model is called a custom model. Custom models are customized versions of master data models or application models. You can use custom models to make business logic customizations to an instance. For example, if your module is used by multiple clients, it's possible to fine-tune the way the modules work for each instance without changing the application models and accompanying code. You can create instance-specific workflows, actions, and modifications to the model structure using custom models.
Aside from the distinction of who created them, the structure and use of models are identical whether they are part of the Core or custom models.
Models are made up of data fields, similar to creating a plain old Java object (POJO) or a database table. In fact, when you create a model the build scripts in the SDK create POJO classes and database tables from the model's definition.
The model's data structure is only the beginning. In addition to being a vehicle to process and persist data fields, models have some unique features:
Models have Views associated with them. Views are somewhat similar to the like-named concept from database architectures. They allow you to define named configurations containing a sub-set of the fields within the model. These views can subsequently be used to form simple user interface screens such as list/detail views.
Models have Actions associated with them. Actions are transactional operations such as create, update, or delete. You can define required fields, permissions for each action, callbacks, and define state transitions for each Action.
Models have Issue Computations associated with them. This allows you to develop based on the 80 / 20 principle. In most normal business scenarios, eighty percent of your data operations, in the business context, work as expected. Which is to say 80% of the orders you process is likely simple normal transactions with no special processing required, while very often there are that 20% of transactions that are outside the norm and require special attention. Issue Computation allows you to do things like raise issues in response to events in any given process.
Models have Workflows. Workflows allow you to define business logic within a transactional wrapper. You can work with any model operation, such as create or update, by querying the new state, comparing it with any existing state, and acting accordingly, all before the transaction is written to the database.
Models are automatically integrated. In addition to POJO code and a database schema, Studio automatically generates everything you need for SOAP bindings as well as JSON, XML, and CSV based integration points.
Models have Audit Trails. If you turn on audit trail tracking, every transaction is recorded as a state change in the audit trail. You can see which users changed what data on which dates.