Introduction to Developing with Finance and Operations Apps (MB500LP01)

Introduction to Developing with Finance and Operations Apps
1 Topic
Learning Path Agenda
Module 1: Explore the Ecosystem and Main Components
8 Topics
Introduction
Finance and Operations Apps and Associated Apps
Finance + Operations On-premises and Cloud-based Finance and Operations Apps​
Development and Deployment Processes
The User Interface
Reporting Capabilities
Knowledge Check
Summary
Module 2: Explore the Technical Architecture
10 Topics
Introduction
Differentiate Cloud and On-premises Architecture
Elements, Models, and Packages
Application Components and Architecture
Metadata Management Processes
Source Control Processes
Conform Code to Organization Policies
Overview of Lifecycle Services
Knowledge Check
Summary
Module 3: Explore Design and Deployment Considerations
11 Topics
Introduction
Identify Relevant Business Concepts
Evaluate functional specifications and create technical design documentation
Identify the technical gaps
Design Patterns and Practices for Code Deployments
The Process for Deploying Code Changes
Finance and Operations Apps Frameworks
Implement the SysOperation framework
Implement the SysOperationSerializer framework
Knowledge Check
Summary
Module 4: Manage Implementations by Using Lifecycle Services
7 Topics
Introduction
Perform Support Tasks
Provision and Manage Environments
Manage Asset Libraries
Manage the Code Update Process
Knowledge Check
Summary
Module 5: Work with Performance and Monitoring Tools
9 Topics
Introduction
Diagnose Performance Issues by Using Trace Parser
Load Testing by Using the Performance SDK
Monitor Performance by Using SQL Insights
Create a SQL Trace by Using the SQL Profiler
Monitor Server Health Metrics in Lifecycle Services
Exercise – Use the Environment Monitoring Tool in Lifecycle Services
Knowledge Check
Summary
Module 6: Manage Source Code by Using Version Control
6 Topics
Introduction and Objectives
Configure Visual Studio to Connect to Azure DevOps
Working in Visual Studio
Manage and Perform Code Reviews
Knowledge Check
Summary
Module 7: Explore the Test Framework and Tools
11 Topics
Introduction
Unit Test Framework
Acceptance Test Library
Task Recorder
Best Practices Tool
Identify Various Categories and Types of Errors
Configure the Testing Environment and Prepare Data
Run Unit Tests
Document and Fix Issues
Knowledge Check
Summary
Activity 1
2 Topics
Group discussion: Testing methodologies, Scenario 1/2
Group discussion: Testing methodologies, Scenario 2/2
Module 8: Explore Reporting Tools
7 Topics
Introduction
Create and Modify Report Data Sources and Supporting Classes
Implement Reporting Security Requirements
Publish a Report
Exercise – Set Authorization Requirements on Database Tables
Knowledge Check
Summary
Activity 2
1 Topic
Lab 1: Create a new module & workspace
End Section
1 Topic
Learning Path Recap
Previous Topic
Next Topic

Implement Reporting Security Requirements

You can use this role-based security to grant user access to reports that are based on roles.

You can access the Security configuration page by going to System administration > Security > Security configuration.

Data security is used to deny user access to tables, fields, and rows in the database. Data security uses the extensible data security framework (XDS) to control access to transactional data by assigning data security policies to security roles. These policies can restrict access to data, based on either the effective date or user data. We recommend that you use the extensible data security to help secure data.

In addition to these security options, the Table Permissions Framework can help protect data and is enforced by the Application Object Server (AOS). The Table Permissions Framework allows you to grant or deny Create, Read, Update, or Delete (CRUD) permissions to the data in a table. You can use this to give certain roles access to view and manipulate certain datasets.​

Table permissions framework example​

Table Permissions Framework adds table-level security that verifies user rights regardless of the request origin. For example, consider the following scenario:​

  1. ABC Corporation implemented finance and operations apps. Users can access data within the application.​
  2. The administrator configured a security role named Management. Members of this role have access to sensitive financial data. One of the tables that stores the sensitive financial data is named ManagerFinancialData. Previously, this table was added as part of a customization for the application.​
  3. The administrator configures the ManagerFinancialData table so that AOS must authorize all operations for that table.​
  4. Before allowing Read access to data in the ManagerFinancialData table, AOS will verify that the user is a member of the Management role and that members of that role have permissions to read the data. If the user is not a member of the Management role, AOS will deny the read operation.​