Agent Pools and Its type

In this blog of DynamicsCommunity101 we will learn Azure DevOps Agent Pools and Their type

In Azure DevOps, an agent pool is a collection of agents used to run your build and deployment jobs. An agent is a computing infrastructure with installed agent software that runs one job at a time.

Agent Pools:

Agent pools allow you to segregate the workloads among different sets of agents based on demands, workloads, or requirements. They provide a level of abstraction between the pipeline definitions and the agents.

Types of Agent Pools:

1. Default Pool: Automatically created in your Azure DevOps environment, which can be used to host self-hosted agents.

2. Hosted Pools: Provided by Azure DevOps, where Microsoft manages the infrastructure. These pools provide different kinds of environments to run your jobs.

Agent Types:

1. Microsoft-hosted agents: These are provided and managed by Microsoft. You don't need to set up anything; just use them in your pipelines. They are automatically updated and patched by Microsoft, offering a range of OS options for your jobs.

2. Self-hosted agents: These are the agents that you set up and manage on your own infrastructure. They can be physical, virtual, in a container, on-premises, or in the cloud. Using self-hosted agents allows you to install custom software needed for your builds and deployments, and they can also have access to your internal network resources.

Why Choose One Over the Other?

- Microsoft-hosted agents are great for starting quickly without the need to manage infrastructure. They provide clean environments for each run, which is excellent for consistency and isolation but might be slower due to the setup and teardown time for each job.

- Self-hosted agents are beneficial when you need more control over the environment, require specific software that's not available in the hosted agents or want to use your own machines to save costs or use specific hardware.

Also Self-hosted agent is very good for security: we are able to disable MFA for 1 specific IP address to push package from DevOps to LCS, rather than Microsoft hosted agent with multiple IP. Credits : Simon

How to deploy Azure pipeline agent on Windows - Self-hosted Windows agents :

Microsoft reference:

Deploy an Azure Pipelines agent on Windows - Azure Pipelines | Microsoft Learn

Preview in MS Articles

Preview in Microsoft articles

In the context of the article "Enable Copilot capabilities in finance and operations apps (preview)" from Microsoft, the term "preview" indicates that the Copilot capabilities for finance and operations apps are currently in a pre-release stage. This means that the features are available for users to test and provide feedback on, but they are not yet fully released or finalized. Preview features are typically made available to gather user insights and identify any potential issues or improvements before a full, stable release is rolled out. Users should note that preview features might be subject to changes, may not be fully supported, and should be used with caution in production environments.

NRP(Net Requirements Planning)

NRP(Net Requirements Planning) in Dynamics 365 FO for Efficient Inventory and Production Management

In Dynamics 365 Finance & Operations (Dynamics 365 F&O), NRP typically refers to "Net Requirements Planning" This feature is part of the Advanced Planning and Scheduling (APS) module, which helps businesses manage and plan their inventory and production processes efficiently.

Net Requirements Planning in Dynamics 365 F&O calculates the net requirements for items based on existing supply (like inventory on hand, purchase orders, and production orders) and demand (such as sales orders, production orders, and forecasts). NRP takes into account various parameters, including lead times, safety stock levels, and reorder points, to generate planned purchase orders, production orders, transfer orders, and kanban orders.

This planning tool is crucial for businesses to maintain optimal inventory levels, ensure timely availability of materials, plan production schedules effectively, and ultimately meet customer demands efficiently while minimizing costs.

So this was all about NRP(Net Requirements Planning) in Dynamics 365 FO for Efficient Inventory and Production Management

Dataverse

Understanding Dataverse in Business Applications

DataVerse, previously known as Common Data Service, is a platform provided by Microsoft as part of the Power Platform suite. It's not a database in the traditional sense but rather a platform that allows users to securely store and manage data used by business applications. DataVerse provides a unified and consistent data schema, ensuring that data is accessible and usable across applications.

While DataVerse acts as a data storage and management platform, the underlying database technology it uses is Azure SQL Database. This means that the actual storage and retrieval of data within DataVerse occur on Azure SQL Database, providing the robust, scalable, and secure database capabilities that Azure is known for. This integration allows users to leverage SQL-based capabilities for data querying and management, while also benefiting from the advanced security, data integration, and compliance features offered by DataVerse.(In simple words you can say DataVerse is a tool from Microsoft that helps you store and manage data for business apps. It's not just a simple database; it's more like a special platform that makes sure your data is organized and can be used easily by different apps. Even though it's not a traditional database, it uses Azure SQL Database from Microsoft to store all the data. So, in a way, DataVerse makes it simpler for you to handle data for your apps, and it uses a powerful Microsoft database in the background to do so.)

I hope now you have a better understanding of Dataverse in Business Applications

Configure a T2 Environment

In this blog of Dynamics Community 101 we will learn How to configure a T2 Environment in D365 FO LCS

To Configure a T2 Environment, follow the below steps

1. Login to LCS with an "environment manager" or a "project owner" role.(This is one of the prerequisites on How to configure a T2 Environment in D365 FO LCS)

2. You will see all the Tier-2 environments on the right side. The one which is not configured you will see as shown below.

3. Click on configure, you will see a dialog box like below.

4. Select the application version and platform version, and click next.

5. Now you will see the environment topology, select it. It will take you to the next dialog page as shown below.

6. Give a suitable name to the environment in 1st field and in the 2nd field select your region.

Click Next. You will see the next screen like this.

7. Click next, and you will see the below screen. (You are done half way on How to configure a T2 Environment in D365 FO LCS).

8. now select the DataSet for the application database, in my case I will select none as shown below.

9. Now click next, and you will see a BPM library screen as shown below, click next.

10. The next screen shows Power Platform Integration(If you want to enable click on it else click next).

11. Click next, and you will see the "Environment Notifications" screen where you can enter the email ID of users who need to receive notifications regarding the environment, click next.

12. Now you will see the Environment administrator screen where you can set the administrator of the environment. as shown below.

13. After selecting click next. Then you will see a screen like below.

14. Now click next, and you will see a screen like below for "Customer sign off", type in your admin name and click Deploy.

15. Now your environment will deploy and you will see the state as Deploying as shown below.

This will take an average time of 2 hours depending on the type of environment and various other factors. You can monitor the deployment progress from the Environment section. Once it is deployed you will see the state as Deployed, as shown in the picture below.

Tada!!!

I hope now you are clear on How to configure a T2 Environment in D365 FO LCS.

All about PPAC

In this blog of DynamicsCommunity101 we will learn All about PPAC

Microsoft reference:

PPAC

Useful reference: 

Unified developer experience

Movement journal

In this blog of DynamicsCommunity101 we will learn about Movement Journal in D365 FO

A movement journal in Dynamics 365 Finance & Operations (F&O) serves as a digital ledger for tracking the internal movement of inventory without involving sales or purchases. It facilitates the management of items being transferred from one location to another within the company, adjusts inventory quantities, and modifies inventory statuses. This ensures that inventory levels and locations are accurately maintained, which is essential for sustaining an organized and efficient inventory management system.

In-depth references

Inventory Movement Vs Adjustment journals in D365 FO

Movement ,Transfer,Counting Journal in D365 FO

Microsoft reference

Inventory journals

DEV SIT UAT PREPROD PROD

Dynamics 365 FO Lifecycle: Navigating DEV SIT UAT PREPROD PRODUCTION Environments - SDLC

In the Dynamic world of ERP, mastering the lifecycle of software development is crucial for ensuring seamless operations and maximizing efficiency. This approach not only streamlines the deployment of new features and customizations but also significantly reduces the risk of disruptions to critical business processes, setting the stage for operational excellence and innovation.

Here’s a brief overview of each stage:

Development (DEV): This is where new features, customizations, and fixes are built. It's primarily used by developers.

System Integration Testing (SIT): In this environment, the developed features are deployed to test their interaction with other modules and third-party systems. It's focused on identifying and fixing integration issues.

User Acceptance Testing (UAT): Here, end-users test the new functionalities to ensure they meet business requirements. This stage is crucial for obtaining user approval before moving changes to production.

Pre-Production (PreProd): This environment mirrors the production environment as closely as possible and is used for final testing and training without affecting the live system. It's the last step before deployment where performance and security can be tested in a production-like environment.

Production (Prod): This is the live environment where all business operations are conducted. Changes are deployed here only after thorough testing in the previous stages.

This cycle ensures that by the time changes reach the production environment, they have been thoroughly developed, tested, and approved, minimizing the risk of disruptions to business operations. However, the exact names and number of environments can vary between organizations based on their specific requirements, size, and complexity of the implementation. Some organizations might include additional stages or merge some based on their project management methodologies.

I hope this blog of DynamicsCommunity101 helped you learn Dynamics 365 FO Lifecycle: Navigating DEV SIT UAT PREPROD PRODUCTION Environments - SDLC

Types of LCS user roles

In this blog of Dynamics Community 101 we will learn Types of LCS User roles

In Dynamics 365 Finance & Operations (F&O), within Lifecycle Services (LCS), there are two primary role categories when adding users to a project: 

1. Project Security Roles

2. Implementation Roles.

Project Security Roles 

It determine the level of access a user has to the LCS project itself.

Project Owner: 

Has full access to the project, including the ability to add or remove users and change their roles.

Environment Manager: 

Can manage cloud-hosted environments, including deploying and monitoring them.

Project User: 

Has basic access to view the project but cannot make changes to the project settings or environments.

Implementation Roles 

They are specific to the tasks and phases of the implementation process of Dynamics 365 F&O. They define the level of access and capabilities a user has within the project’s operational scope, including the configuration and setup of the Dynamics 365 environment. They include:

Solution Architect: 

Responsible for overall solution design and ensuring the implementation meets business requirements.

Functional Consultant: 

Focuses on configuring the application to meet client processes and requirements.

Technical Consultant: 

Handles customizations, integrations, and technical aspects of the Dynamics 365 environment.

Developer: 

Specializes in writing and testing code, creating customizations, and developing integrations.

Business Analyst: 

Analyzes business processes and interfaces between business and technology.

Thank you. This LCS users role blog was by Dynamicscommunity101 Atul

Query range D365 FO

In this blog of Dynamics Community 101 we will learn the Query range

Using OR:

QueryBuildRange qbr =SysQuery::findOrCreateRange(_qbds, fieldNum(HcmPerfJournal, Owner));

qbr.value(strFmt(‘(%1.%2 == %3) || (%1.%4 == %5)’,

_qbds.name(),

fieldStr(HcmPerfJournal, Owner), enum2int(HcmPerfManagerEmployee::Manager),

fieldStr(HcmPerfJournal, Share), enum2int(NoYes::Yes)));

qbr.status(RangeStatus::Hidden);

Using AND:

queryBuildRange = accessRightsListDataSource.addRange(fieldnum(DEL_AccessRightsList, RecId));

queryBuildRange.value(strfmt(‘((%1.%2==%3) && (%1.%4==%5))’,

accessRightsListDataSource.name(),

fieldstr(DEL_AccessRightsList, RecordType),

accessRecordType,

fieldstr(DEL_AccessRightsList, Id),

_securityKeyArray.value(i)));

Date Range:

queryBuildRange .value(SysQueryRangeUtil::dateRange(DateTimeUtil::date(DateTimeUtil::addDays(currentDateTime,relativeDaysFrom)), DateTimeUtil::date(DateTimeUtil::addDays(currentDateTime,relativeDaysTo)));

or

queryBuildRange.value(SysQuery::range(fromDate, toDate));

Adding multiple Query range x++

Log off user

Auto log-off users who have been logged in for more than 8 hours in Dynamics 365 FO

public void autoUserLogOff()

{

SecurityUserRole securityUserRole;

SecurityRole securityRole;

container usersList;

SysClientSessions sysUserSession;

utcDateTime dateTime, dateTimeLocal;

TimeOfDay totalHours;

SysUsersTerminate usersTerminate;

SysUserInfo userInfo;

str timeValue;

#define.AOTName(‘-SYSADMIN-‘)

#define.Admin(‘Admin’)

dateTime = DateTimeUtil::newDateTime(systemDateGet(), timeNow());

while select Id from userInfo

where userInfo.Id != #Admin

{

select firstOnly RecId from securityUserRole where securityUserRole.User == userInfo.Id

exists join securityRole where securityRole.RecId == securityUserRole.SecurityRole

&& securityRole.AotName == #AOTName;

if (securityUserRole.RecId)

continue;

while select * from sysUserSession

where sysUserSession.userId == userInfo.Id

&& sysUserSession.sessionType == SessionType::GUI

{

dateTimeLocal = DateTimeUtil::applyTimeZoneOffset(sysUserSession.LoginDateTime, DateTimeUtil::getUserPreferredTimeZone());

totalHours = int642int(DateTimeUtil::getDifference(dateTime, dateTimeLocal));

timeValue = conPeek(str2con(time2StrHM(totalHours), “:”),1);

if( str2int(timeValue) >= 8)

{

usersList += [[sysUserSession.userId, sysUserSession.SessionId, sysUserSession.LoginDateTime]];

}

}

}

if (conLen(usersList) > 1)

{

usersTerminate = SysUsersTerminate::newUsersList(usersList);

usersTerminate.run();

}

}

Autouser log off user x++

I hope this blog of DynamicsCommunity101 helped you learn Auto log-off users who have been logged in for more than 8 hours in Dynamics 365 FO

lookup field of a standard form

Custom/Change-standard  lookup field of a standard form using register override method

/// <summary>

/// Extension of SalesTable form.

/// </summary>

[ExtensionOf(formStr(SalesTable))]

final class LSSalesTableFormV1_Extension

{

     /// <summary>

    /// init method.

    /// </summary>

    public void init()

    {

        next init();

        // CR 4526 - start.

        LSParameters    lsParameters;

        boolean         ret;

        FormRun         formRun;

        FormDataSource  salesTable_ds;

        SalesTable      salesTableLoc;

        lsParameters  = LSParameters::find();

        ret           = lsParameters.SalesCumulativeDiscount ? true : false;

        formRun = this;

        salesTable_ds = formRun.dataSource(formDataSourceStr(SalesTable, SalesTable));

        if(LSParameters::find().ExternalItemNumberinSOLine == NoYes::Yes)

        {

            FormStringControl SalesLine_ItemId = this.design().controlName(formControlStr(SalesTable, SalesLine_ItemId));

            SalesLine_ItemId.registerOverrideMethod(methodStr(FormDataObject, lookup), formMethodStr(SalesTable, LSSalesLine_ItemId));

        }

    }

    public void LSSalesLine_ItemId(FormStringControl _formControl)

    {

        Query                   query = new Query();

        QueryBuildDataSource    qbds,qbds2;

        QueryBuildRange         qbr;

        SysTableLookup          sysTableLookup;

 

        qbds = query.addDataSource(tableNum(LSInventTableExternalItem));

        //qbds.addRange(fieldNum(InventTable, ItemType)).value("Item");

        //qbds2 = qbds.addDataSource(tableNum(CustVendExternalItem));

        //qbds2.relations(false);

        //qbds2.joinMode(JoinMode::OuterJoin);

        //qbds2.addLink(fieldNum(CustVendExternalItem, ItemID), fieldNum(InventTable, ItemID));

 

        sysTableLookup = SysTableLookup::newParameters(tableNum(LSInventTableExternalItem), _formControl);

        sysTableLookup.addLookupfield(fieldNum(LSInventTableExternalItem, ItemId));

        sysTableLookup.addLookupfield(fieldNum(LSInventTableExternalItem, NameAlias));

        sysTableLookup.addLookupfield(fieldNum(LSInventTableExternalItem, ItemType));

        //sysTableLookup.addLookupfield(fieldNum(LSInventTableExternalItem, ExternalItemId));

        

        sysTableLookup.parmQuery(query);

        sysTableLookup.performFormLookup();

 

    }

}

I hope this blog of DynamicsCommunity101 we learnt the Custom/Change-standard  lookup field of a standard form using register override method

Service update in Dynamics 365

Changes in pausing service updates in Dynamics 365

Service update:

Microsoft is committed to delivering predictable service updates. These service updates are made generally available for self-deployment before Microsoft automatically applies them. The timing of the package release for self-update relative to the production auto-updates varies. To determine the timing of self-updates and auto-updates for upcoming releases, see the Targeted release schedule (dates subject to change).

Customers can take up to four service updates per year and are required to take a minimum of two per year. Customers can choose to pause one update at a time. A pause of a service update can apply to the designated user acceptance testing (UAT) sandbox environment, the production environment, or both environments. After the pause window ends, if the customer hasn't self-updated to a supported service update, Microsoft automatically applies the latest update, based on the configuration in Microsoft Dynamics Lifecycle Services. To learn more about how to pause service updates, see Pause service updates through Lifecycle Services.

Note: Service updates are provided four times annually. Auto-updates occur in February, April, July, and October.

Proactive Quality updates(PQU):

PQUs are cumulative builds of hotfixes that are delivered with near-zero downtime. PQUs follow a push model, where updates are applied to a Microsoft Dynamics Lifecycle Services environment in the background and have minimal impact on customers. Every PQU is deployed region by region, by following a "safe deployment process" that tracks issues that are found within each region during deployment. The safe deployment process helps identify and fix issues before the PQU is deployed to more regions. PQUs are 100 percent automated and contain important bug fixes that are ready after the service update is generally available. 

Pause service updates through Lifecycle Services (LCS)

Note : 

Service updates are provided four times annually. Auto-updates occur in February, April, July, and October.

 

Four types of update:

1. Qumulative update/Service updates

2. Proactive quality updates - A bunch of hotfixes that get applied in almost no downtime

3. Hot fix - very minor updates/bug fixes

4. Platform update - 59 to 60 for bugs from MS

 

 

The moment we pause the update from LCS, it stops for service update, proactive, or hotfix.

I hope this blog on Changes in pausing service updates in Dynamics 365 was useful.