Move AOT elements between models

In order to move the objects from one model to another model, we opt to copy -paste from original model`s physical folder to destination model`s folder. This is feasible when we have limited objects. but if the object count is more, this approach is tedious.

So here is another way to move the objects from one model to another.

1. Open the project which has all the objects.

2. In the same solution, create another project and set its model to the new one .

3. Drag and drop the objects from the above project to the new one .

4. Sync and Rebuild.

5. Now the objects are ready in new model .

This way our job becomes easy and we can be sure the objects are not missed because there are chances of missing the objects when they are moved across physical locations.

Database restore from bacpac file - D365 FO

 We may have to restore the database in D365 environment in order to get the latest data and configurations in the system. To get the latest dat we should have a backup file of the database taken from other environment. 

The back up files can of two types

• .bak 
• .bacpac

Restoring a ".bak" file in to SQL server involves the direct process to get the latest data base. But if the file type is of ".bacpac" then it is not the same way as a ".bak" file.

Restoring a ".bacpac" file needs a different approach than the regular database back up file Below are the steps to be followed to restore the bacpac file in to SQL Server.

1. Open command prompt with Admin rights

2. Use the below command to navigate to the folder 

• Cd C:\Program Files (x86)\Microsoft SQL Server\140\DAC\bin

      Note : If 140 or 150 not available then install update for dac framework. Install DAC

3. Execute the below command

• SqlPackage.exe /a:import /sf:Your file path /tsn:localhost /tdn:AXDB_New /p:CommandTimeout=1800
• File path example : C:\Temp\YourbacpacName.bacpac

4. Login to SQL Server with Admin user

5. Select the newly created DB (AXDB_New) in previous steps and execute the following SQL command in it.

6. Rename AXDB to AXDB_Old.

7. Rename AXDB_New to AXDB.

SQL Script to be executed

CREATE USER axdeployuser FROM LOGIN axdeployuser

EXEC sp_addrolemember 'db_owner', 'axdeployuser'

CREATE USER axdbadmin FROM LOGIN axdbadmin

EXEC sp_addrolemember 'db_owner', 'axdbadmin'

CREATE USER axmrruntimeuser FROM LOGIN axmrruntimeuser

EXEC sp_addrolemember 'db_datareader', 'axmrruntimeuser'

EXEC sp_addrolemember 'db_datawriter', 'axmrruntimeuser'

CREATE USER axretaildatasyncuser FROM LOGIN axretaildatasyncuser

EXEC sp_addrolemember 'DataSyncUsersRole', 'axretaildatasyncuser'

CREATE USER axretailruntimeuser FROM LOGIN axretailruntimeuser

EXEC sp_addrolemember 'UsersRole', 'axretailruntimeuser'

EXEC sp_addrolemember 'ReportUsersRole', 'axretailruntimeuser'

CREATE USER axdeployextuser FROM LOGIN axdeployextuser

EXEC sp_addrolemember 'DeployExtensibilityRole', 'axdeployextuser'

CREATE USER [NT AUTHORITY\NETWORK SERVICE] FROM LOGIN [NT AUTHORITY\NETWORK SERVICE]

EXEC sp_addrolemember 'db_owner', 'NT AUTHORITY\NETWORK SERVICE'

UPDATE T1

SET T1.storageproviderid = 0

    , T1.accessinformation = ''

    , T1.modifiedby = 'Admin'

    , T1.modifieddatetime = getdate()

FROM docuvalue T1

WHERE T1.storageproviderid = 1 --Azure storage

DROP PROCEDURE IF EXISTS SP_ConfigureTablesForChangeTracking

DROP PROCEDURE IF EXISTS SP_ConfigureTablesForChangeTracking_V2

GO

-- Begin Refresh Retail FullText Catalogs

DECLARE @RFTXNAME NVARCHAR(MAX);

DECLARE @RFTXSQL NVARCHAR(MAX);

DECLARE retail_ftx CURSOR FOR

SELECT OBJECT_SCHEMA_NAME(object_id) + '.' + OBJECT_NAME(object_id) fullname FROM SYS.FULLTEXT_INDEXES

    WHERE FULLTEXT_CATALOG_ID = (SELECT TOP 1 FULLTEXT_CATALOG_ID FROM SYS.FULLTEXT_CATALOGS WHERE NAME = 'COMMERCEFULLTEXTCATALOG');

OPEN retail_ftx;

FETCH NEXT FROM retail_ftx INTO @RFTXNAME;

BEGIN TRY

    WHILE @@FETCH_STATUS = 0 

    BEGIN 

        PRINT 'Refreshing Full Text Index ' + @RFTXNAME;

        EXEC SP_FULLTEXT_TABLE @RFTXNAME, 'activate';

        SET @RFTXSQL = 'ALTER FULLTEXT INDEX ON ' + @RFTXNAME + ' START FULL POPULATION';

        EXEC SP_EXECUTESQL @RFTXSQL;

        FETCH NEXT FROM retail_ftx INTO @RFTXNAME;

    END

END TRY

BEGIN CATCH

    PRINT error_message()

END CATCH

CLOSE retail_ftx; 

DEALLOCATE retail_ftx; 

CrossCompany and changeCompany using x++

 CrossCompany:

    Required company filter:

    MyTable 	myTable; 
    container 	conCompanies = ['cmp1', 'cmp2', 'cmp3'];

    while select crossCompany : conCompanies * from myTable
    {
	// code
    }

    All company filter:

    MyTable 	myTable; 

    while select crossCompany * from myTable
    {
        // code
    }

    Applying On Dynamic queries:

    Query 			query = new Query();
    QueryRun 			queryRun;
    QueryBuildDataSource 	qBDS;

    qBDS = query.addDataSource(TableNum(CustTable));
	
    // Way-1 (we can add required company)
    query.allowCrossCompany(true);
    query.addCompanyRange('cmp1');
    query.addCompanyRange('cmp2');

    // Way-2 (It will loop all company)
    queryRun = new QueryRun(query);
    queryRun.allowCrossCompany(true);

Change Company:

    MyTable 	myTable; 

    changeCompany('cmp1')
    {
        while select myTable 
        {
           // code
        }
    }

“Application specific parameters are not set correctly for the configuration” in electronic reporting - D365 FO

The issue is due to specific parameters are not configured properly as per legal entity.

This problem usually occurs when the specific parameters of a format version are “In Progress” state, while they should be in a “completed” state.

Go to “Workspace” > “Electronic reporting” and click on “Reporting configurations.”

Select your ER Format and click on Configurations > Setup.

Select your last active completed version and look at the state value.

If it’ “In progress” modify it in “Completed” state

After modified Save it by pressing Save button.

Difference - Refresh, Reread, Research and Execute query

 Refresh

• refresh () will not reread the record from the database. It basically just refreshes the screen with whatever is stored in the form cache.

Reread

• reread () will only re-read the CURRENT record from the DB so you should not use it to refresh the form data if you have added/removed records.  It’s often used if you change some values in the current record in some code, and commit them to the database using .update() on the table, instead of through the form data source.  In this case, .reread () will make those changes appear on the form.

ReSearch

• research() will rerun the existing form query against the data source, therefore updating the list with new/removed records as well as updating existing ones.  This will honor any existing filters and sorting on the form.

ExecuteQuery

• executeQuery () is another useful one.  It should be used if you have modified the query in your code and need to refresh the form.  It’s like research () except it takes query changes into account.

Track user sign-in In D365FO

 Many organizations are required to maintain an audit trail of users who have used the system. This requirement can be in place for compliance reasons, or to enable trackbacks in the event of incorrect use.

In Microsoft Dynamics AX 2012, the Audit log form recorded which users accessed the Microsoft Dynamics AX environment. In Microsoft Dynamics 365 finance and operations apps, this information is captured in telemetry. IT administrators can download this information by using Microsoft Dynamics Lifecycle Services (LCS) and then move it to offline storage to maintain the audit trail of users who have signed in.

To generate an audit log of users who have used the system, follow these steps.

1. Sign in to LCS and open the project that is associated with your implementation.
2. Navigate to the production environment and open the Environment details page.
3. On the Monitoring tab, select the Environment monitoring link to open the monitoring dashboard.
4. On the Activity tab, select View raw logs.
5. In the Query field, select User Login Events. You see a time duration that has a start date that is set to End date - 7 days.
6. Set the end date, and then select Search. The search results that are returned include all users who signed in to the system during the seven days before the selected end date.
7. The search results show the AADUserID value and the sign-in start and end times of the user's session. To map the AADUserID value to the user's username and email address, use the Users page (System administration > Users).
8. To export the records and keep them for a longer period, select Export grid.