Type = FAQs,; Topic = Opus Solution Environment,;Persona = Solution Designer,; Orchestration = Manufacturing, Logistics, Commerce, Transportation, Clinical Supply,; Function = Supply Chain, IT, Operations, Regulatory Affairs, Quality, Commercial, Pharmacy, Project Management, Finance, Procurement,

Concepts and terminologies

The following terms explain how the OPUS Solution Environment (OSE) manages objects, permissions, workflows, and user interactions across the platform.

Application (app)

A product offering that includes one or more functions to meet customer and market needs. OPUS apps are exposed as APIs. They are headless, meaning they do not have a built-in user interface.

Solution

TraceLink apps are extended through solutions, which pull together assets that define how the app looks and functions when users interact with it (i.e. business objects, pages, workflows, roles, and policies).

TraceLink offers three types of solutions:

  • Standard Solutions - These solutions are preinstalled by TraceLink and are available to all companies. They provide baseline functionality that addresses common requirements across multiple companies. Users cannot configure these solutions, which ensures consistent and reliable deployment.
  • Marketplace Solutions - These solutions offer a broader range of functionality designed to meet specific business needs. Solution Partners and TraceLink internal teams create Marketplace Solutions to address complex challenges within a company and across trade partners. Users cannot configure Marketplace Solutions.
  • Company Solutions - These solutions are highly configured for a specific company. Solution Designers configure Company Solutions to meet their company's specific needs and processes. Solution Designers can create and configure a new Company Solution either by saving a copy of a Standard Solution or a Marketplace Solution or by creating a new Company Solution from scratch. Company Solutions support extensive configuration of pages, menus, roles, business objects, and workflows providing a flexible and adaptive solution that can evolve with the company’s changing needs.

Catalog

A compilation of solutions (e.g. MINT, POET) with varying levels of configurability. Catalogs are differentiated by the scope of the catalog items.

Orchestration

An orchestration is the coordinated execution of multiple business processes across different business objects, each with its own workflow, to represent a broader business relationship. Orchestrations are crucial for managing complex supply chain operations, enabling companies to quickly adapt to changes, ensuring compliance, and optimizing overall performance through real-time data exchange and collaboration.

Business Object

A business object is a digital representation of a thing that users interact within the OPUS UI. These objects typically represent documents, messages, or some other collection of information that needs to be communicated between two business partners (e.g. a purchase order, receipt, or shipping notice are all business objects).

A specific instance of a business object (e.g. a single purchase order) is called an object instance or simply an object. In the past, these were once physical documents, on the OPUS Network, they are digital objects containing the same information that can be easily communicated and tracked through their lifecycle.

Page type

Page types are the means for Solution Designers to create pages for their solutions. They provide the structure that all pages must follow, which ensures that the organization of information across all pages in a solution is consistent. This reduces the potential for mistakes when designing a page and provides a streamlined user experience for a solution's users. The sections and fields available for a given page are based on the solution's primary object. Page type ensures data is presented consistently across the solution and in the best possible format to fulfill the page's objective.

Page types leverage standard object operations, which also accelerates the design and development of the solution, eliminating the overhead of complex application logic.

There are 3 page types; New, View/Edit, and Search.

  • New page - Allows Solution Designers to create new object instances (e.g. create a new purchase order).
  • View/Edit page - Allows Solution Designers to view an existing object instance. The page's View mode shows the contents of the business object, and the Edit mode allows them to edit the business object's data (e.g. view or edit an existing purchase order).
  • Search page - Allows Solution Designers and users to search for instances of business objects and filter the search results based on specified criteria. The results appear in the Object table, which can be sorted by one or more columns.
    The Search page is typically the default page displayed when solution users select a menu item from a solution's side menu.

Page elements

A component is a metadata-driven element in the OPUS Solution Environment (OSE), which provides a flexible, intuitive user experience without requiring extensive coding.

A section serves as a container for components, providing structure to fields, collections, and groups for better information presentation in the solution.

A field is a data element within a business object that captures specific types of information (e.g. text, numbers, or dates). Fields can be grouped into collections for better organization and are integrated into the UI for data entry and display. They can include validation rules and support dynamic behavior, such as showing or hiding based on other field values.

The following field types are avaialble:

  • AutoNumber
  • Boolean
  • Date
  • Date Time
  • File Attachment
  • Lookup By Value
  • Media
  • MultiPickList
  • Number
  • Percent
  • PickList
  • Standard PickList
  • Text
  • Text Area
  • URL

A collection is a group of related data elements displayed in the user interface as a single field or set of fields. Depending on the context, collections often appear as lists or tables. Like individual fields, collections have properties that define their behavior and structure (e.g. line items in a purchase order are typically grouped into a collection and displayed in a table).

A group organizes related fields in the user interface so they are always displayed together (e.g. an Address group might contain both Ship to Address and Ship from Address fields).

A field collection is a type of data element that allows multiple values in a single object. For example, a purchase order object might contain several transaction IDs, stored as a collection within that object.

A group collection is a set of logically connected fields that can be grouped together within a form section. Grouping related fields improves the usability of the form by helping users enter and view contextually related information more easily.

The operation referes to the action that a user can perform on a given business object (e.g. Create New PO).

Role

Roles control permissions for pages, functions, and data within an app and solution, whether accessed through the user interface or B2B integration. In the OPUS Solution Environment (OSE), Solution Designers defines roles and assigns permissions to them. TraceLink Administrators with Role Management access then assign these roles to users.

Each solution can have multiple roles to manage what different users can see and do within the solution. At a minimum, every enterprise solution must include one user with a System Administrator role, while multienterprise solutions must also include a System Administrator user for the Partner. TraceLink provides a set of default roles with each standard or marketplace solution, which can be extended via OSE.

Policy

A policy defines the expression that determines whether a user with a particular role is authorized to perform a specific action (e.g. acting on an object in a particular solution). This expression is evaluated instantly when the user initiates the action, with a response time in sub-milliseconds. TraceLink provides a set of predefined policies with each app, and Solution Designers and Developers have permission to update policies for the solutions they license.

Authorization

Authorization in OSE controls what actions users are allowed to perform after authentication, ensuring access aligns with defined security policies. It enforces access control rules to enhance platform security and compliance by restricting actions based on assigned permissions.

Enforcement point

An enforcement point is a specific location in the application where security policies are evaluated and enforced. It controls access to data and actions based on a user’s roles and permissions, using the authorization token to verify read or write access.

Permissions

Permissions define the actions users can perform within the system and are typically assigned through user roles. Administrators manage roles and permissions in the OSE UI, allowing for granular control of access by creating roles, editing them, and assigning permissions based on organizational needs.

Workflow

A workflow is defined as a set of states and transitions for a business object. Workflows facilitate business objects through their correlating real world business process by defining sequences of states (steps) and transitions, made up of transition conditions and post-transition actions.

There are two types of workflows:

  • Standard workflow - Includes a predefined sequence of states and transitions for an object type. These workflows are commonly used across various business processes.
  • Business object workflow - Extends a standard workflow to support unique requirements. It provides configuration options and flexibility to adapt the standard workflow model to specific business needs.

Workflow elements

A state represents the current condition of an object within a workflow. States are used to track and manage the lifecycle of documents or transactions as they move through defined stages. In OSE, workflows use states to enforce processing rules and ensure that each object advances through the appropriate steps with the required validations.

A base state represents one of the primary states that an object can occupy within a workflow. For example, Draft, In Review, and Approved are base states defined by the Solution Developer. These states are not customizable by customers.

A substate is a more specific state that exists within a base state in a workflow. Substates provide additional detail about an object’s status and allow for more granular control and tracking as the object progresses through its workflow.

Workflow transitions define how an object moves from one state or substate to another within its workflow. Transitions are managed by using two key configurations: transition conditions and post-transition actions. Transition conditions determine when a transition is allowed, while post-transition actions define what happens after the transition occurs. Together, these configurations ensure that objects progress through their workflows in a controlled and predictable manner.

Tag end