Ax2012 Enus Deviv 03 PDF

Chapter 3: Application Foundation Features
CHAPTER 3: APPLICATION FOUNDATION FEATURES

Objectives
The objectives are: Describe how to set up and use the Global Address Book. Review the data model and classes for the Global Address Book framework. Create a new entity for the Global Address Book. Modify the Extensible Data Security policy for the new Global Address Book entity. Retrieve an address from the Global Address Book on a transaction. Describe how extensible data security policies can be used to help secure your data. Create and use extensible data security policies. Describe how financial dimensions are used. Describe the various types of organizations available in Microsoft Dynamics AX 2012. Describe how the organization model is used throughout the system. Create a custom operating unit, and organization type. Describe how cases are used in Microsoft Dynamics AX 2012. Create a new case association type. Add case management to a form. Explain how policy rules are used. Review the data model for the policies framework. Create a new policy type and policy rule.
Introduction
There are many application foundation features in Microsoft Dynamics AX 2012. This chapter introduces several of these features. Global address book: This feature serves as a central repository for addresses throughout the system. Extensible data security policies (XDS): You can use the XDS policies to control the security of data within the system. Financial dimensions: Financial dimensions provide additional details in the general ledger and serve as segments in the chart of accounts.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
3-1
Development IV in Microsoft Dynamics AX 2012

Organization model: You can use the organization model to structure legal entities and organization units for security, reporting, and other functionality within the system. Case management: You can use cases to track information about issues that are related to various data points within the system. Policies: Users can use policies to define rules in various modules to help guide the flow of business inside a particular process.
Global Address Book

The global address book (GAB) framework in Microsoft Dynamics AX 2012 is used to share information across Microsoft Dynamics AX companies and entities through a central repository of users and organizations. It is improved to make sharing easier. This course highlights the patterns used to consume or update address book controls. This includes party name/details and postal and electronic addresses.
Benefits and Features

Microsoft Dynamics AX 2009 introduced the address book framework. Each person or organization in the address book is referred to as a party. Records stored in the repository about parties are called party records. Party records include name, address, contact information, and person/organization data. In Microsoft Dynamics AX 2012, roles that are associated with party records are referred to as party roles. Party roles include customer, vendor, prospect (formerly known as business relations), contact, worker, applicant, competitor, legal entities, operating units, teams, prospective vendors, and personal contacts. A single party can be associated with one or more party roles in a Microsoft Dynamics AX company. For example, the organization party of A. Datum Corporation can be associated with a customer, prospect, and vendor in the Microsoft Dynamics AX company CEE and can also be associated with a vendor in the Microsoft Dynamics AX company CEU. Benefits of this shared data include the following. Demonstrates how people and organizations have relationships with other areas of the enterprise. The relationship and communication between two organizations changes when one organization has more than one role such as a vendor and customer. There might be special agreements that can be negotiated to encourage a closer partnership with the other organization. Ease of setup and maintenance. For example, when a change is made to an address, the update only has to be made in one place; all of the other associated records are updated automatically.
3-2

Data Normalization
Most of the transactions and journals have address information for example: sales orders have delivery addresses, and invoices have billing addresses. In earlier versions of Microsoft Dynamics AX the address is stored on the header and each line for each transaction. Additionally, the address is also stored with the journals or packing slips that are generated from the transaction. This pattern caused significant repetition of data. For example, entering a 10-line quotation and moving it step-by-step to an invoice means the same address could be stored 88 times. In Microsoft Dynamics AX 2012, address duplication is reduced by storing the address one time and having each transaction or journal table reference the address record.
Address Defaulting
An address defaulting methodology is implemented that lets users select which address should be used as the default for a transaction. The customer, vendor, legal entity, and prospect forms let the user specify a default address for a specific purpose. Depending on the transaction, there are different defaulting flows for addresses.
Terminology
The terms used with the GAB include the following. Party: A person or organization. A party can be internal or external to an organization. Address book: Group of parties. Party roles: Entities that refer to customers, vendors, competitor, worker, applicant, and prospect are a few examples. Non-party entities: Refers to inventory, bank group, bank accounts, and so on. Location: Refers to either a postal address or electronic address (contact information such as telephone, fax, URL, email, telex).
3-3

Party and Address Book Data Model
The following figure shows the core party and address book data model.
FIGURE 3.1 CORE PARTY AND ADDRESS BOOK DATA MODEL
In the earlier versions, the party tables, including DirPartyTable, are striped by dataArea, and are shared across companies by virtual tables. In Microsoft Dynamics AX 2012, the use of dataArea is removed for party related tables. This means that the party data is not saved for each company (SaveDataPerCompany = No). Party tables are now shared, which means that the need for setting up virtual tables is eliminated. In Microsoft Dynamics AX 2012, names for organization and person are now date-effective. Date-effective names are supported by the use of the ValidTimeStateFieldType property of the table. The affected tables include DirOrganizationName and DirPersonName.
3-4

Postal Address and Contact Information Data Model
The following figure shows the postal address and contact information data model.
FIGURE 3.2 LOCATION DATA MODEL
In the earlier versions, primary address and contact information for party entities is stored in the table for each entity (vendor, customer, worker, contact person, prospect (business relation), applicant, competitor, and external and internal organizations. In Microsoft Dynamics AX 2012, the Address table is now deprecated and is replaced by the shared table LogisticsPostalAddress. All address fields are now removed from party and non-party related tables. Information from these tables moved to the LogisticsPostalAddress table. Contact information fields are now also removed from party related tables and moved to the LogisticsElectronicAddress shared table. Non-party related contact information fields remain unchanged.
3-5

In Microsoft Dynamics AX 2012, the primary address and contact information is now stored in the shared tables LogisticsPostalAddress and LogisticsElectronicAddress. Unlimited numbers of records can be created for postal address and contact information by using a relationship table. For example, DirPartyTable uses DirPartyLocation to associate party record to locations. In Microsoft Dynamics AX 2012, postal address and contact information are data-effective. This enables you to create future effective records and keeps track of changes to these records.
DirPartyLookup Class
Both the DirPartyRecId and DirPersonRecId extended data types automatically inherit the lookup for party or person without any filter. If you need the lookup to be filtered, you can use the DirUtility::nameLookup() or DirUtility::personNameLookup() to do this. This uses the DirPartyLookupEntitiesFilter class to filter by the party role. For more information, refer to the following code sample taken from the AuditPolicyAdditionalOption form.
public Common lookupReference(FormReferenceControl _formReferenceControl) { Common ret; dirPartyLookupEntitiesFilter dirPartyLookupEntitiesFilter; dirPartyLookupEntitiesFilter = dirPartyLookupEntitiesFilter::generateDirPartyLookupEntitie sFilter( (auditPolicyListParty.AddressBookRole == DirPartyRoleView::All ? NoYes::Yes : NoYes::No), (auditPolicyListParty.AddressBookRole == DirPartyRoleView::CustomersOnly ? FilterStatus::Set : FilterStatus::Undefined), (auditPolicyListParty.AddressBookRole == DirPartyRoleView::VendorsOnly ? FilterStatus::Set : FilterStatus::Undefined), (auditPolicyListParty.AddressBookRole == DirPartyRoleView::BusinessRelationsOnly ? FilterStatus::Set : FilterStatus::Undefined),
3-6

(auditPolicyListParty.AddressBookRole == DirPartyRoleView::CompetitorsOnly ? FilterStatus::Set : FilterStatus::Undefined), (auditPolicyListParty.AddressBookRole == DirPartyRoleView::ContactsOnly ? FilterStatus::Set : FilterStatus::Undefined), (auditPolicyListParty.AddressBookRole == DirPartyRoleView::EmployeesOnly ? FilterStatus::Set : FilterStatus::Undefined)); (auditPolicyListParty.AddressBookRole == DirPartyRoleViewApplicantsOnly ? FilterStatus::Set : FilterStatus::Undefined)); ret = DirUtility::namelookup(_formReferenceControl, auditPolicyListParty, DirPartyType::None, element, false,
dirPartyLookupEntitiesFilter); return ret; }
The AuditPolicyListParty table contains the list of monitored parties by an audit policy. During audit policy execution, the list of monitored parties will be returned defined for the policy and the documents associated with the parties will be checked for audit policy violation.
Adding an Address to an Entity

When you add an address to an entity in Microsoft Dynamics AX, you must first determine whether the entity should have one address or multiple addresses. The following forms are examples that use single address logic. BankAccountTable BankGroup IntrastatParameters CustBankAccounts VendBankAccounts HcmWorkerBankAccounts
3-7

TIP: Because creating postal addresses involves large amounts of logic, including validation, formatting, and field references; we recommend that you use the LogisticsPostalAddress form to manage new addresses. The following forms are examples that use multiple address logic. CustTable tutorial_Form_GABPrimitive HcmApplicantBasket InventLocation VendTable HcmWorker
Procedure: Add a Single Address to an Entity

To add a single address to an entity, follow these steps. 1. Use or extend the LogisticsPostalAddressFormHandler class to implement single address on a form. 2. Create menu items for the New, Edit, Clear and Map buttons with the following properties. When you are finished creating the menu items, add them to the form in a button group. a. Label = @SYS2055 (New), @SYS2475 (Edit), @SYS2079 (Clear), @SYS136333 (Map) b. ObjectType = Class c. Object = LogisticsPostalAddressFormHandler d. EnumTypeParameter = LogisticsLocationAddressActionButtons e. EnumParameter = New, Edit, Clear or Map f. OpenMode = New or Edit (do not set on Clear and Map) g. NormalImage = 11045 (New), 7696 (Edit), 10563 (Clear), 10041 (Map) h. ImageLocation = EmbeddedResource 3. On the form where the address part will be added do the following. a. Add the form handler class in the classDeclaration.
public class FormRun extends ObjectRun { LogisticsPostalAddressFormHandler addressController; // or the new derived class }
b. Add a form method called getAddressController.
3-8

public LogisticsPostalAddressFormHandler getAddressController() { return addressController; }
c. Override the main data source active method.

public int active() { int ret; ret = super(); if (ret) { addressController.callerActive(); addressController.callerUpdateButtons(newAddress, editAddress, clearAddress, mapButton); } return ret; }
d. Add LogisticsPostalAddressTable as a data source and override the validateWrite and write methods.
public boolean validateWrite() { return true; } public void write() { //super(); }
TIP: We recommend that you use the right-click > Duplicate feature in the Application Object Tree (AOT) and the drag-and-drop functionality. This also works for methods.
Procedure: Add Multiple Addresses to an Entity

To add a single address to an entity, complete the following steps. 1. Use or extend the LogisticsEntityPostalAddressFormHandler class to implement unlimited address association.
2. Create menu items for the Add, Edit, Deactivate, Remove, Advanced and Map buttons with the following properties. a. Label = @SYS2318 (Add), @SYS2475 (Edit), @SYS23466 (Advanced), @SYS134283 (Deactivate), @SYS311855 (Remove), @SYS136333 (Map)
3-9

b. ObjectType = Class c. Object = LogisticsEntityPostalAddressFormHandler d. EnumTypeParameter = LogisticsLocationAddressActionButtons e. EnumParameter = 0 New, 1 Edit, 3 Map, 4 Delete, 5 Advanced, 6 Deactivate f. LinkedPermissionType = Form g. LinkedPermissionObject = LogisticsPostalAddress h. NormalImage = 11421 (Add), 10040 (Edit), 10106 (Advanced), 11438 (Delete), 10041 (Map), 10039 (Deactivate) i. ImageLocation = EmbeddedResource j. OpenMode = New, Edit, Auto (for Advanced, Map, Delete and Deactivate) 3. 4. Add these menu items on the Action Pane in your form. Create a grid with LogisticsEntityPostalAddressView as the data source, set as Passive linkType, AutoSearch=No. Do the following. a. Add the placeholder variable for the selected/active postal address in the classDeclaration.
public class FormRun extends ObjectRun { LogisticsLocationRecId postalAddressLocation; }
b. Add a form method called parmPostalAddressLocation.

public LogisticsLocationRecId parmPostalAddressLocation(LogisticsLocationRecId _postalAddressLocation = dirPartyPostalAddressView.Location) { postalAddressLocation = _postalAddressLocation; return postalAddressLocation; }
c. Override the main data source active method.

public int active() { int ret; ret = super(); if (ret) { LogisticsEntityPostalAddressView_ds.executeQuery(); } return ret; }
d. Add LogisticsEntityPostalAddressView as a data source and override the executeQuery method.
3-10

public void executeQuery() { DirPartyPostalAddressView::updateQuery(this.query().d ataSourceName(this.name()), custTable.Party); super(); this.updateButtons(); if (postalAddressLocation != 0 && postalAddressLocation != dirPartyPostalAddressView.Location) { this.findValue(fieldnum(DirPartyPostalAddressView,Loc ation),SysQuery::value(postalAddressLocation)); } }
Global Address Book Security

You can set security privileges to party records in the following ways: Secure by legal entity: Security privileges are based on the legal entity that a party is associated with. If you secure party records by legal entity, workers can only access the records that are associated with any legal entity that the worker has access to. Secure by address book: Security privileges are based on teams. With this method, only workers who are assigned to a team that has access to an address book can view the party records in that address book. Secure by both legal entity and address book: Security privileges are based on both legal entities and teams.
You can create address books at any time and if you select, you can set security parameters for the address books at any time. Setting security for address books is not required in Microsoft Dynamics AX. However, if you do not restrict access by legal entity, or if security privileges are not set for an address book, all workers in your organization can view all party records. You can use the Security policy options link in the Global address book parameters form to select whether the enforcement of security privileges for address books is based on teams, legal entities, or both. Each method for setting security privileges on the global address book uses an extensible data security (XDS) policy in the AOT. When you add a new global address entity, we recommend that you add your address entity tables as constrained tables to the appropriate security policies in the AOT.
3-11
Extensible Data Security Policy Framework

Developers and administrations can use security policies to block access to subsets of rows in tables. A policy resembles a where clause in an SQL select statement. A security permission increases the access a user has to data. But a security policy decreases access to data. In the AOT, policies are displayed under Security > Policies. Security policies are enforced in the Application Object Server (AOS). All access mechanisms that route through the AOS are subject to policy enforcement. These access mechanisms include forms, Enterprise Portal webpages, SSRS reports, and calls from class methods.
FIGURE 3.3 CONCEPTUAL MODEL OF EXTENSIBLE DATA SECURITY
Concept Review
The following list defines the concepts of the XDS model. Primary table You can use a primary table to help secure the content of the related constrained table. For example, in a policy restricts access to all sales orders based on the CustGroup foreign key value, the Customer table would be the primary table. Policy query You can define a policy query by specifying a value for the Query property in the AOT at Security > Policies > YourPolicy. You can use a policy query to help secure the constrained tables specified in a given security policy. The query selects data from a primary table. The values in that data are then used to restrict the data returned from the constrained table.
3-12

Constrained tables and views A security policy could constrain the data access of the SalesTable to only those records that have one particular CustAccount foreign key value. You can define constrained tables and views in the AOT at Security > Policies > YourPolicy > Constrained Tables. Context A policy context controls the circumstances under which a given policy applies. The policy is not enforced unless the context is set. The types of policy contexts are as follows. Role context: Can enable policies that are based on the roles to which the user is assigned. Application context: Can enable policies that are based on information which is set by the application.
Security Policies
A policy specifies the table row or record that can be accessed. This resembles the WHERE clause in a SQL view or statement that specifies the table records to be returned. All security policies start with a query that is defined under AOT > Queries. The VendProfileAccountPolicy query, shown in the following image, is the basis for the policy that is described in this topic.
FIGURE 3.4 VENDPROFILEACCOUNTPOLICY QUERY
3-13

Range Affects the Security Policy This figure shows a range on the query. The range requires that the field VendProfileAccountPolicy. User has a value of the (currentUserID()) (which returns the user who is currently logged on), on every data record that users in the associated role can view. This means the policy will prevent access to VendProfileAccountPolicy table records that are not for the current user. NOTE: There is a second range on the table that requires the VendProfileAccountPolicy.ExternalEntityType to be equal to Vendor. Relation Affects the Security Policy This relation works in combination with the range. This relation means the policy will prevent access to records in the UserExternalParty table unless those records are related to a VendTable record that has User equal to the current user logged on and the externalEntityType is equal to vendor. The most important property of a policy is its Query property. The PrimaryTable property is set to the first data source of the query. The following figure has the VendProfileAccountpolicy node highlighted under AOT > Security > Policies.
FIGURE 3.5 VENDPROFILEACCOUNT SECURITY POLICY
3-14

This figure shows the ConstrainedTable property of the policy. No: Means the policy does not restrict the data values in records that are returned from the primary table. Yes: Means the policy does restrict the data values in records that are returned from the primary table.
Trimming
The security configuration of each field is assessed for the current user. This security behavior is called field trimming because the restricted fields are trimmed out of the results before the results are sent from the AOS to the client. The code sample scans all fields that are under AOT > Data Dictionary > Tables, for a specified range of tables. When a user runs a query, the system can refuse to send data from the AOS for particular columns that the current user has no authorization to access. The access is controlled by the AOSAuthorization property that is available on each field during run time. This property value cannot be known at compile time. The run time value of the AOSAuthorization property is controlled by the roles that the user belongs to. The following code sample scans the system tables to find fields that the current user cannot access, on tables that he can otherwise access. The code prints progress reports to the Print window while it runs. The final output of field names appears in the Infolog window. The macros near the top of the code sample are explained in a section that follows the code sample.
static void GmTrimAccessFieldScan3Job(Args _args) { // Edit the following three macro values to your needs. For example: // ** Start: with a table whose name starts with an 'A'. // ** Stop: with a table whose name starts with a 'Z'. #define.SearchTableNameRangeStart("") #define.SearchTableNameRangeStop("") #define.TargetTableNameLikeFilter("*") TreeNode tnTable, tnField; str sTableAosAuth, sFieldAosAuth; int nCountOfTpfTablesFound = 0, nCountOfAotTables = 0, nCountOfTrimmedFields = 0; // Establish start node among the table nodes. if (#SearchTableNameRangeStart =="") {
3-15

tnTable = TreeNode::findNode ("\\Data Dictionary\\Tables").AOTfirstChild(); } else { tnTable = TreeNode::findNode ("\\Data (file://\\Data) Dictionary\\Tables\\" + #SearchTableNameRangeStart); } while (true) { nCountOfAotTables++; // Provide ongoing progress reports. if ((nCountOfAotTables MOD 50) == 3) { print int2Str(nCountOfAotTables) + " tables examined to this point, at " + tnTable.AOTname(); print int2Str(nCountOfTpfTablesFound) + " TPF okay tables found to this point."; print int2Str(nCountOfTrimmedFields) + " trimmed fields found to this point."; print "---------------- Wait..."; } // Perhaps stop before the end of the AOT, for convenience. if (#SearchTableNameRangeStop < tnTable.AOTname() && #SearchTableNameRangeStop !="") { break; } // Apply the table name wildcard filter. if (tnTable.AOTname() like #TargetTableNameLikeFilter) { sTableAosAuth = tnTable.AOTgetProperty('AOSAuthorization'); // Test whether there is authority to access the table, under TPF. if (sTableAosAuth != 'None') { nCountOfTpfTablesFound++; // Loop through the fields on this table. for (tnField = TreeNode::findNode ('\\Data Dictionary\\Tables\\' + tnTable.AOTname()
3-16

'\\Fields').AOTfirstChild(); tnField.AOTnextSibling() { + tnField; tnField = )
sFieldAosAuth = tnField.AOTgetProperty('AOSAuthorization'); // Test whether there is authority to access the field. if (sFieldAosAuth != 'No') { nCountOfTrimmedFields++; info(strFmt('%1 %2 is a trimmed field that you cannot access.', tnTable.AOTname(), tnField.AOTname())); } } // for each field in AOT } // if table is guarded by the Table Protection Framework (TPF). } // name is Like // Prepare for next iteration of this loop. tnTable = tnTable.AOTnextSibling(); if (tnTable == null) break; } // for each table in AOT print "-------- Final Report (see also the Infolog) --------"; print int2Str(nCountOfAotTables) + " tables examined to this point, at end."; print int2Str(nCountOfTpfTablesFound) + " TPF tables found to this point, at end."; print int2Str(nCountOfTrimmedFields) + " trimmed fields found to this point, at end."; print "-------- Done. --------"; pause; }
TIP: You can import the AX2012_ENUS_DEVIV_03_TRIMMINGJOB.xpo provided with your training image. The file contains the code sample provided.
3-17

Demonstration: Create a Simple Default Security Policy
The following steps demonstrate how to add an XDS policy for specific customer groups.
Inspect that Data You Want to Help Secure

1. Open the Microsoft Dynamics AX client. 2. Open Accounts receivable > Setup > Customers > Customer groups. 3. Verify that the Major customers customer group has an ID value of 20. You will create a policy so that an application user can only work with data for this customer group.
Create a Query for Your Security Policy

Each security policy relies on a query. The ranges of the query are a primary element of the security policy. You can create a new policy query by following these steps: 1. Create a policy query by right-clicking the Queries node in the AOT, and then clicking New > Query. Rename the new query to MajorCustomersPolicyQuery. 2. Locate Data Sources under the MajorCustomersPolicyQuery node. Add a new data source. 3. In the Properties window for the new data source, set the Name property to CustGroup_1, and the Table property to CustGroup. 4. Right-click the Ranges node and select New Range. 5. In the Properties window for the new range, set the Field property to CustGroup, and the Value property to 20. 6. Locate Fields under the MajorCustomersPolicyQuery > Data Sources > CustGroup_1 node. 7. In the Properties window for Fields, set the Dynamic property to Yes. The Yes value indicates that all fields are queried.
Create a Security Policy

You can create a security policy by following these steps: 1. Expand the Security node in the AOT window, and then right-click the Policies node and select New Security Policy. Rename the new security policy to MajorCustomersPolicy. 2. In the Properties window for MajorCustomersPolicy, set the following properties: o Name = MajorCustomersPolicy o Label = Restrict data to major customers o PrimaryTable = CustGroup o Query = MajorCustomersPolicyQuery
3-18

o o o o PolicyGroup = Customer group based policy ConstrainedTable = Yes Enabled = Yes Operation = All operations
3. Save and compile the security policy. The security policy is now ready for deployment and testing. Notice that the ContextType property is currently set to the value ContextString, but the ContextString property is empty. This combination implies that when it is enabled, this security policy will always be applicable for all users.
Verify that the Security Policy is Enforced

As an application user, you can now verify that the security policy that you have created is enforced by the system. 1. Assign an application user to the Sales manager role. Open System administration > Setup > Security > Assign users to roles. 2. Log on to the system as that application user. 3. Open Accounts Receivable and open Setup > Customers > Customer groups. 4. Verify that the application user can view only the Major customers customer group. 5. Try to insert a record and verify that the application user cannot add any other customer group. When you try to insert a record, the code output to the Infolog window is visible , and you receive the following error message. "Cannot create a record in Customer Groups (CustGroup). Security Policy permission denied."
Demonstration: Constrain Access to Related Tables

In this demonstration a pre-existing security policy is modified to reduce the range of data records that roles and users can access in the CustTable table and the SalesTable table. You do this by adding the two tables under the Constrained Tables node of the pre-existing policy. The security policy already exists for the CustGroup table. The pre-existing security policy is named MajorCustomersPolicy. The PrimaryTable property of the policy names the CustGroup table. Foreign key relations are used by the policy to determine which data records the users are authorized to access on the constrained tables. The CustGroup table is a parent of the CustTable table, which has a foreign key field that references the primary key of the CustGroup table. And the CustTable table is a parent of the SalesTable table.
3-19

Add to the List of Constrained Tables on the Policy
You can add tables to the list under the Constrained Tables node of a security policy. The policy denies access to some data records in the constrained tables. The particular records that are denied are determined by the foreign key relationships among the tables in the policy. A record on a constrained table can be accessed only if the foreign key value in the record matches the primary key value of a record that can be accessed in the primary table of the policy. You can add the CustTable table as a constrained table by following these steps: 1. Right-click the Constrained Tables node on policy MajorCustomersPolicy, and then click New > Add table by relation. 2. Set the Table property to CustTable. 3. Set the property TableRelation to CustGroup.
Chains of Constrained Tables in a Policy

In this section, you constrain the SalesTable table. You constrain it by associating it to the constrained CustTable table that you added in the previous section. The SalesTable table is related to the CustGroup table indirectly through the CustTable table. You constrain the SalesTable table by following these steps: 1. Right-click the node MajorCustomersPolicy > Constrained Tables > CustTable, and then select New > Add table by relation. 2. Set the Table property to SalesTable. 3. Set the TableRelation property to OrderCustomer.
Constrain Views by the Policy

There are no named relations between a view and a table, the way there are between two tables where a formal foreign key is defined. However, in a security policy under its Constrained Tables node, you can define a relation between a view and one of the tables that the view references. You do this by setting the Value property of the view to a value that has the following format: (Table.FieldName=View.FieldName). You can also enter multiple field relations in the following format: ((Table.Field1=View.Field1) && (Table.Field2=View.Field2)). In the following steps, you improve the security policy to constrain access to data from a view. 1. Right-click the MajorCustomersPolicy > Constrained Tables > CustTable node and select New > Add table or view by free form expression. 2. Set the Value property of the view to (smmCustomerView.Party = CustTable.Party).
3-20

Verify that the Security Policy is Enforced on Related Tables and Views
As an application user, you can now verify that the security policy that you have created is enforced by the system. 1. Manually assign an application user to the Sales manager role by using the System administration form. 2. Log on to the system as that application user. 3. Open Accounts Receivable and open Common > Customers > All Customers. Verify that only customers in customer group 20 are shown. Confirm that you can personalize the form and add the Customer.CustomerGroup field to the form. 4. Verify that the application user can only see the Major customers customer group. 5. Open Sales and marketing and open Common > Sales orders > All sales orders. 6. Verify that you can only view the sales orders for customers of the Major customers group.
Demonstration: Add Role Context to a Security Policy

In this demonstration a policy is modified to apply it to security roles.
Change the Security Policy to Specify a Security Role

1. Change the ContextType property on the policy node MajorCustomersPolicy to RoleName. 2. Set the RoleName property on the policy node to TradeSalesManager.
Verify that the Security Policy is Enforced

As an application user, you can now verify that the new security policy is enforced by the system. 1. Manually assign an application user to the Sales manager role by using the System administration form. 2. Log on to the system as an application user. 3. Open Accounts Receivable > Setup > Customers > Customer groups. 4. Verify that the application user can only view the Major customers customer group. NOTE: You can run another test as another user who is not assigned to the Sales manager role, but does have access to customer groups to verify that all customer groups are available when the Sales manager role is not assigned.
3-21
Lab 3.1 - Extensible Data Security Policies

This lab demonstrates how to create a new extensible data security policy for a specific group of customers. Estimated time to complete this lab: 15 minutes Scenario Claire, the HR Manager, should only be able to view vendors that are in the employee vendor group. Employees are currently assigned to the "Other" vendor group. Simon, the Business Systems Developer, must create a new extensible data security policy to restrict the HR Manager role to only view Other vendors.
Challenge Yourself!
Use the information that is provided to create a new extensible data security policy for the HR Manager role that restricts access to view only vendors in the Other group.
Need a Little Help?

1. 2. 3. 4. 5. Review the Vendor groups form in Accounts payable > Setup. Create a new query for the VendGroup table. Create a new security policy that uses the query that you created. Add table constraints for the VendTable and PurchTables. Set the ContextType and Role properties on the security policy.
Step by Step
Inspect the Data You Want to Help Secure
1. Open the Microsoft Dynamics AX client. 2. Open Accounts payable > Setup > Customers > Customer groups. 3. Verify that the Other vendors vendor group has an ID value of 80. You will create a policy so that an application user can only work with data for this vendor group.
3-22

Create a Query for Your Security Policy
To create a new policy query, follow these steps. 1. Expand the Security node in the AOT window, and then right-click the Policies node and select New Security Policy. Rename the new security policy to OtherVendorsPolicyQuery. 2. Locate Data Sources under the SecurityPolicy > OtherVendorsPolicyQuery node. Add a new data source. 3. In the Properties window for the new data source, set the Name property to VendGroup_1, and the Table property to VendGroup. 4. Right-click the Ranges node and select New Range. 5. In the Properties window for the new range, set the Field property to VendGroup, and the Value property to 80. 6. Locate Fields under the OtherVendorsPolicyQuery > Data Sources > VendGroup_1 node. 7. In the Properties window for Fields, set the Dynamic property to Yes. The Yes value indicates that all fields are queried.
Create a Security Policy

To create a security policy, follow these steps: 1. Create a security policy query by right-clicking the AOT, and then clicking New > Security > Security Policy. Rename the new security policy to OtherVendorsPolicy. 2. In the Properties window for OtherVendorsPolicy, set the following properties: o Name = OtherVendorsPolicy o Label = Restrict data to other vendors o PrimaryTable = VendGroup o Query = OtherVendorsPolicyQuery o PolicyGroup = Vendor group based policy o ConstrainedTable = Yes o Enabled = Yes o Operation = All operations 3. Save and compile the security policy.
Constrain Tables
You can add the VendTable table as a constrained table by following these steps: 1. Right-click the Constrained Tables node on the OtherVendorsPolicy policy, and then click New > Add table by relation. 2. Set the Table property to VendTable.
3-23

3. Set the property TableRelation to VendGroup. 4. You constrain the SalesTable table by following these steps: o Right-click the node OtherVendorsPolicy > Constrained Tables > VendTable, and then select New > Add table by relation. o Set the Table property to PurchTable. o Set the TableRelation property to OrderVendor.
Specify a Security Role

1. Change the ContextType property on the policy node OtherVendorsPolicy to RoleName. 2. Set the RoleName property on the policy node to HCMHumanResourceManager. TIP: You can import the AX2012_ENUS_DEVIV_03_01_LAB_SOL.xpo file to verify and compare your solution.
3-24
Financial Dimension Framework

You can use financial dimensions to track additional dimension values when entered in account entry controls along with a main account. The order in which these dimensions are entered and constraints of the valid values are defined by account structures, and optionally by account rules and rule structures. System-defined: The values of these financial dimensions are derived from an existing entity also known as the backing entity. For example, the Customer system-defined dimension uses the values from the CustTable. You do not need to maintain a separate list of customers in dimensions and cannot add new values specifically as dimension values that are not already used as a customer directly somewhere else. The values in the backing entity table (CustTable in this example) are automatically used as the dimension values. User-defined: The values for these financial dimensions are maintained solely within the financial dimensions module and have no meaning or usage outside of financial dimensions. To create a user-defined financial dimension, select < Custom dimension > in the Use values from list field on the Financial dimensions form.
Dimensions in the System

Out of the box, no financial dimensions are provided. The user must define each financial dimension to be tracked and for user-defined dimensions, the list of values to select from. The dimensions must then be added as segments to an account structure or an advanced rule structure to be used throughout the system. Once these structures are activated and added to the chart of accounts, transactions in each legal entity that the chart of accounts is linked to can use the dimensions. Dimension values can be defined on master data such as customers or vendors. The dimension information is then merged to transactional data such as purchase orders and sales orders as default values, which the user can override. For example, when a sales order invoice is generated, the dimensions are merged to the update tables that are used for invoicing, and then merged to the customer transactions, invoice tables, and general ledger transaction tables when the document is posted.
Development with the Financial Dimension Framework

Your business requirements might require that you extend the financial dimension framework. There are two basic ways that you can use the framework. Making a table dimensionable by adding it as a system-defined dimension. This is done by creating new DimAttribute[entityName] views.
3-25

Adding account entry or dimension controls to the user interface. This is done by using one of the financial dimension controller classes that are provided with Microsoft Dynamics AX 2012. A few examples of controllers that can be used include LedgerDimensionAccountController, LedgerDimensionDefaultAccountController, and the DimensionDefaultingContoller classes.
NOTE: For more information about the financial dimension framework and examples of adding controls to forms and creating a new system-defined dimension, refer to the Use and Design of the Ledger Module chapter in this course.
Organization Model Framework

The organization model represents internal control, data security access, and performance reporting structures designed to divide responsibility for human and operations resources and work processes. The organization model in Microsoft Dynamics AX 2012 introduces two new conceptslegal entity and operating unit.
Legal Entities
A legal entity is an organization with a registered or legislated legal structure that is granted the authority to enter into legal contracts that is required to prepare statements that report on its performance. A legal entity and company in Microsoft Dynamics AX 2012 are semantically the same. However, some functional areas in the application are still based on a data model that uses company (or DataArea). These areas can have the same limitations as in Microsoft Dynamics AX 2009, and can have an implicit data security boundary.
Operating Units
An operating unit is an organization that divides the control of economic resources and operational processes among people who have a duty to maximize the use of scarce resources, to improve processes, and to account for their performance. Several types of operating units are available out of the box. A business unit is primarily an operating organization with a focus on industries or product lines that the organization is supposed to serve. A cost center is a type of operating unit that describes an organization used for tracking costs or expenses. It is a cost accumulator, and is used to manage costs.
3-26

A department is a type of operating unit that can have profit and loss responsibility and could be a grouping of cost centers. Departments are also frequently created based on functional responsibility or skill, such as sales and marketing. A value stream is a type of operating unit typically used in lean manufacturing. In lean manufacturing, a value stream owns one or more production flows that describe the activities and flows needed to supply a product, good, or service to the consumers of the product.
A team is also a type of an internal organization. However, it is an informal group of people primarily created for a specific purpose over a short duration. Teams can be created for specific projects or services. The other types previously described are more permanent, although there might be major restructuring related changes or frequent minor updates. When legal entities and operating units are arranged into hierarchies and used for reporting rollup, security access, and business policies, they help enable internal control of your business.
Organization Hierarchies
You can set up organizational hierarchies to visually model your business from different perspectives. For example, you can set up a hierarchy of legal entities for tax, legal, or statutory reporting. Then you can set up another hierarchy that is based on operating units that represents the way that you report financial information that is not legally required. However, that is used for internal reporting. For example, you can create a purchasing hierarchy to control purchasing policies, rules, and business processes. IMPORTANT: The only way to report based on the hierarchy is through dimensions. Microsoft Dynamics AX 2012 does not use the hierarchy for financial reporting. TIP: Microsoft Dynamics AX 2012 does not support the hierarchies in the account structures. If you have at least two segments backed by an organization unit in the hierarchy, you can select the hierarchy in the Configure account structure form by clicking the Relationships button. When you do this, the system will adhere to the hierarchy and not force users to also set up the constraints in the account structure. Organizations in a hierarchy can share parameters, policies, and transactions. An organization can inherit or override the parameters of its parent organization. However, shared master data, such as products and address books, applies to the whole organization and cannot be overridden for individual organizations.
3-27

NOTE: For more information about how to plan and implementing the organization model, refer to the Organization Model chapter in the Installation and Configuration course, or the "Implementing and Extending the Organization Model" white paper.
Application Scenarios
The organization model is integrated with the application modules in Microsoft Dynamics AX. There are two types of scenarios: The organization model framework is integrated with other application frameworks. Transaction scenarios use integrations to create end-to-end scenarios.
The organization model is tightly integrated with following frameworks.
Address Book
All internal organizationslegal entity, operating unit, and teamare types of the Party entity. This means that these organizations take advantage of the capabilities of the address book to store address and contact information.
Financial Dimensions
Legal entities and operating units can be used to define financial dimensions, and those financial dimensions can be used in account structures. By using organizations as financial dimensions, you can perform an analysis of an organizations financial performance. The relationships between organizations described through hierarchies can also be used as constraints if two types of organizations are used as separate financial dimensions in the account structure.
Policy Framework
In Microsoft Dynamics AX 2012, a business policy can be defined for an organization by using the policy framework. The policy framework can be used to define policies for expense reports, purchase requisitions, audit control of documents, and vendor invoice payments. The policy framework provides support for override and default behavior for organizations based on their hierarchies, and enables internal management control of organizations to facilitate cost control, fraud detection, better operating efficiency, and better performance generally.
Extensible data security

Companies provided the data security boundary for most application data in previous releases. The new extensible data security framework provides capabilities to help secure data based on any condition.
3-28

A common scenario for data security is to filter master data or transaction data based on a users association to internal organizations. The master data or transaction data entity must have a foreign key relationship (field on the entity table) with the organization to be able to set up a security policy.
Transaction Scenarios
There are several application areas that use the new organization model framework. The primary effect is in the following modules. Here is a brief description of the usage. For a complete description and steps for the scenarios in these areas, refer to the Help documentation.
Procurement and sourcing

The lines of a purchase requisition are created for a buying legal entity, and they are received in an operating unit such as a cost center or department. A purchase requisition is created for a requester and is prepared by a preparer. Various scenarios are enabled where you could view or create purchase requisitions for all buying legal entities and receiving operating units in which you have access to create requisitions.
Human resources
In human resources, workers hold employment contracts in a legal entity and have a position in a department. All transaction scenarios in human resources take advantage of these concepts to view and modify data.
Travel and expense

Expense reports and lines carry a legal entity to which the expense line item should be charged from a statutory perspective, and they also carry an operating unit for internal reporting.
Development
You can extend the organization model to support customization or special configuration scenarios. One of the core extensibility scenarios is extending the organization model for specific industry vertical requirements such as retail, professional services, or public sector. Branches, stores, schools, and school districts are basically organization concepts. You can model them as new types of operating units. The framework of the new organization model supports this extensibility by allowing you to define a new type of custom operating unit.
3-29

NOTE: In Microsoft Dynamics AX 2012, existing entities such as warehouse, site, and project are not organizations. There are two options if you want to take advantage of the organization model framework for these entities. The first option is to model them as cost centers or departments so that you can incorporate them in the hierarchy and use the framework. We recommend that you use this option. The second option is to model them as custom operating units. In both options, you must manage data separately and keep it consistent. Also, data security access, policies, and dimensions that are defined for organizations that correspond to these entities will not apply to the actual entities. A customization is required if these limitations must be addressed. This customization is out of the scope of this course.
Demonstration: Create a Custom Operating Unit

In the following example, you will configure an operating unit called Branch. To configure Store, do the following. Define a new Base Enum value for the OMOperatingUnitType that corresponds to the new type of operating unit. Define a query OMStoreQuery for the new type of operating unit. Define a view OMStoreView based on the OMStoreQuery query. Optionally, define a new menu item that corresponds to this operating unit to create new instances of this type of operating unit.
To define a new Base Enum value for the OMOperatingUnitType that corresponds to the new type of operating unit, follow these steps. 1. In the AOT, right-click Data Dictionary > Base Enums > OMOperatingUnitType and then click New Element. 2. In the Properties window, enter Store in the Name and Label. 3. Save the base enumeration. To define a query for the new type of operating unit, follow these steps. 1. In the AOT, right-click Queries and then click New Query. 2. In the Properties window, type OMBranchQuery in the Name. 3. Right-click OMStoreQuery > Data Sources and then select New Data Source. 4. In the Properties window, select OMOperatingUnit in the Table property and then press Enter. 5. Expand the new OMOperatingUnit_1 data source and select the Fields node. 6. In the Properties window, set the Dynamic property to Yes. 7. Right-click the OMStoreQuery > OMOperatingUnit_1 > Ranges node and select New Range. 8. In the Properties window, set the Field to OMOperatingUnitType, and the Value to =Store.
3-30

9. Right-click the OMStoreQuery > OMOperatingUnit_1 > Data Sources node and select New Data Source. 10. In the Properties window, set the Table to DirPartyTable and the FetchMode to 1:1. 11. Expand the new DirPartyTable_1 data source and select the Fields node. 12. In the Properties window, set the Dynamic property to Yes. 13. Right-click the Relations node on the new DirPartyTable_1 data source and select New Relation. 14. In the Properties window, set the Field to RecID and the RelatedField to RecID. 15. Save the query. To define a view based on the query that you defined, follow these steps. 1. In the AOT, right-click Data Dictionary > Views and then click New View. 2. In Name, type OMStoreView. 3. In the Properties window, set the following values. o Label = Store o Query = OMStoreQuery o TitleField1 = RecID o TitleField2 = modifiedBy 4. Drag the following fields from the DataSource > Field nodes to the OMStoreView > Fields node. o OMOperatingUnitType o LanguageId o NameAlias o Memo o PartyNumber o InstanceRelationType o KnownAs o Name o OMOperatingUnitNumber o OMOperatingUnitRecId 5. Drag the following fields into the Field Groups > AutoReport node. o RecId o Name 6. Save the view.
3-31

To define a new menu item to create new instances of this type of operating unit, follow these steps. This menu item will open an operating unit form only for creating operating units of the type Store. This step is optional. 1. In the AOT, right-click Menu Items > Display and then click New Menu Item. 2. In Name, type OMStore. 3. In Label, type Store. 4. In Object, type OMOperatingUnit. 5. In EnumTypeParameter, type OMOperatingUnitType. 6. In EnumParameter, type Store. The integration of the organization model with other frameworks provides visibility into this new type of operating unit. You can define new instances of these organizations by using the Operating unit form. (You can also use a parameterized version of the form opened by using the menu item if you performed the optional preceding procedure.) You can use the new instances of the custom operating unit in building new hierarchies within the hierarchy designer without any further changes. You can define data security access for these organizations based on the hierarchies. You can also use the policy framework to set policies for these types of organizations.
Hierarchy Designer Extensibility

In Microsoft Dynamics AX 2012, there is limited support for extensibility of hierarchy designer. The hierarchy designer control can be customized for four parameters of organization nodes within the hierarchy: border color, node image, top gradient color, and bottom gradient color. The following sample code changes to OMHierDesignExtClass to support new values for border, top gradient, and bottom gradient colors based on the type of the organization.
class OMHierDesignExtClass { #ResAppl #define.LegalEntityTopGradient("#FFA5CDFF") #define.LegalEntityBottomGradient("#FF7EB8FF") #define.LegalEntityBorderColor("#FF3F5C80") #define.BusinessUnitTopGradient("#FF89C3E7") #define.BusinessUnitBottomGradient("#FF4C9FD2") #define.BusinessUnitBorderColor("#FF004b78") #define.CostCenterTopGradient("#FFE2FFA6") #define.CostCenterBottomGradient("#FFD6FF80") #define.CostCenterBorderColor("#FF6B8040") #define.DepartmentTopGradient("#FFA6ECFF") #define.DepartmentBottomGradient("#FF80E3FF") #define.DepartmentBorderColor("#FF407280") #define.ValueStreamTopGradient("#FFFFCEA6") #define.ValueStreamBottomGradient("#FFFFB980")
3-32

#define.ValueStreamBorderColor("#FF805D40") #define.DefaultTopGradient("#FFDC143C") #define.DefaultBottomGradient("#FFDC143C") #define.DefaultBorderColor("#FF004b78") FormRun m_HDForm; OMOrganizationHierarchy m_omOH; }
A similar customization can be done for a new type of operating unit by customizing this class to add a new border color, top gradient color, and bottom gradient color. Without the customization, the hierarchy designer uses default colors for a new type of operating unit. You can add a new custom purpose by customizing the OMHierarchyPurposeTableClass class and HierarchyPurpose base Enum. The customization must extend to the application scenario where this custom purpose will be used. For more information about an example of doing this refer to the "Policy Framework" topic in this course. A more complex customization of the OMHierarchyPurposeTableClass class is required if you want to force the design of balanced hierarchies. In a hierarchy, all nodes at a fixed depth from the root node define a level. In a balanced hierarchy, specific operating unit types are allowed at each level. You can set up a new end-to-end scenario or customize an existing end-to-end scenario. The high-level steps are as follows. 1. Define or change the data model. o Create a new transaction table or make a Per company transaction table by changing the metadata property from SaveDataPerCompany = yes to SaveDataPerCompany = No. o Include relevant organizations as Foreign keys (FK) on the table. It is sufficient to carry an operating unit because the relationship with the legal entity is established through organization hierarchies. o If the transaction table carries redundant data of the legal entity field, set up business logic constraints between legal entities and operating units to maintain data consistency. 2. Build a new form (for example, a list page) for the transaction scenarios, or change the existing user experience to view or maintain transactions. The custom filters can help view or manage data across organizations. 3. Apply default organizations on the transaction table in financial dimensions by including them in account structures. 4. Create XDS policies for data security based on access to the organizations of the user. 5. Use the policy framework to set up specific policies that are applied while you are creating a new transaction in the application scenario.
3-33

Special considerations can apply for intercompany trade and intercompany accounting if the transactions are between two legal entities of the same business implemented in one instance of Microsoft Dynamics AX 2012. You must make special considerations if master data entities are referenced in the application scenario because they have a relationship in the data model with the transaction table.
Case Management Framework

Typically, case management is a reference to customer service. However, many business operations can benefit from case management, as described here. Customer service: Customer questions, issues, complaints, and suggestions have to be tracked. Purchasing and receiving: Your organization is a customer to your suppliers, and while you track your customer issues, you should also track issues that you have with your suppliers, such as incorrect or damaged items and late deliveries. Employees working in purchasing and receiving need a place to record issues and complaints about vendors and the products they purchase. This is especially true because this can cause your organization strife, delays in production, and reduce customer satisfaction. Human resources and payroll: Employees are customers of human resources (HR) and payroll departments. These departments have to record any incidents and grievances reported by their workers. Even more than customer service, HR has to follow strict procedures for resolving these issuesnot only for legal reasons, but because many unions require documentation of any complaints. Auditing: Typically, the auditor is responsible for the manual job of reviewing expenses and contracts, and identifying compliance violations. Even when the auditor finds violations, many times there is no form or table record these issues for a historical reference. Collections: Collection agents have to keep a record of the communications and interactions with the people and businesses they are working with. Microsoft Dynamics AX 2012 case management fulfills the needs of these business operations.
Microsoft Dynamics AX 2012 case management fulfills the needs of these business operations. While the goal is to resolve issues as swiftly as possible, not all issues and questions can be resolved quickly and easily. They frequently require more than one interaction in addition to collaboration and research before they can be closed. Organizations need the ability to record and report on these issues.
3-34

Case management provides the tools to handle issues more quickly and improve customer, employee, and vendor relationships, and includes the following. Track and manage defects or improvement requests with integrated action processes. Create, manage, and resolve customer, vendor, and employee cases more easily by automatically tracking all communication activities that go into finding satisfactory resolutions. Let you log dependent cases for complex issues that require more than one resolution path. Associate many records in the system by tying together several components. A case opened for a customer can also be associated with a sales order and a specific item. Linking all the necessary records provides the case worker with the ability to view everything related to a case. Use service level agreements because responding in a timely, effective manner is extremely important to the success of your organization. To meet and exceed expectations, you have to track and measure how quickly you react to issues and escalate to bigger levels of support and management for cases that are not resolved in a timely manner.
Case Process
Organizations need all cases to be handled consistently according to company policies and procedures. To make sure that this occurs, case processes can be defined to guide your workers through a simple checklist or a more elaborate step-by-step set of stages and actions. This provides consistency in resolving cases, and helps new case workers to become efficient and perform at a high level in a short period of time. After a case process is defined, it can be associated with a specific case category so that your case workers will know what has to be completed for each situation. In addition to case processes, workflow can be defined so that cases can be assigned to queues, which can be picked up by any case worker in a specific area, such as auditing.
Knowledge Articles
To resolve cases efficiently, case workers need easy access to processes and procedures, answers to frequently asked questions, how-to documentation, and other organizational knowledge collateral. The ability to create and store knowledge articles provides case workers with the information that they must have to resolve cases quickly. To help ensure even faster resolution, you can associate specific knowledge articles with a case category, which will default the knowledge articles to any case by using that category. This functionality reduces the time that you have to have for a case worker to search for documentation.
3-35

Scenario: Extending the Case Management Framework
Your business might require you to extend the case management framework to other data entities. This might include the ability to associate a case to another record, or the ability to create new cases for other types of records. Scenario: Vince, the Operations Manager, has noticed an increase in the number of calls and the issues when vehicles are rented and returned. He wants a way to record these issues when they are reported so that they can be followed up on. He has decided to start by using case management to help with this process. Case management already exists for customers, so he will be able to track customer calls and requests. However, there is currently no way to create a case for a specific vehicle or rental. Vince wants to create cases for specific vehicles to track the maintenance issues, history, and damage to the vehicles. Additionally, he wants to be able to create cases for specific rentals to help control the return process for vehicles. He wants the inspectors to record information that is collected during the return such as the issues the customer had with the vehicle and the damage that is found on the vehicle when it is returned.
3-36

Case Management Data Model
The following figure shows the data model for case management.
FIGURE 3.6 CASE MANAGEMENT DATA MODEL
The CaseDetailsBase is the primary table for storing all cases regardless of where the case is created from or which records the case is related to. Each case is assigned a case category. Case categories are stored in the CaseCategoryHierarchyDetail table. Each case can have logs or notes related to the case. Each log entry related to a case is stored in the CaseLog table. When a case is related to another case, this reference is stored in the CaseDependancy table. The CaseAssociation table is used to store a reference to each record that a case is related to. The CaseAssociation table is then related to the primary table for each type of association based on the CaseEntityType and RefRecId. For example, when a case is related to a sales order, the CaseEntityType field would store the enum value for the sales order table, and the RefRecId field would store the RecID from the sales order that the case is related to.
3-37

When a case is created from the Enterprise Portal the user details are stored in the CaseWebDetails table. When a Knowledge article is related to a case, it is populated in the TmpSmmKACaseRelation temporary table. Records can be inserted into this temporary table automatically when a case is created based on the set up of the knowledge article or they can be manually added. Each TmpSmmKACaseRelation record is related to a smmEncyclopediaItems table record which is the primary table for knowledge articles. The actual document, URL, or note that is related to a knowledge article is stored in the DocuRef table. This table is the primary table that is used for document handling throughout the system.
Case Associations
Out of the box, cases can be related to the following data entities and tables. Data Entity Lead Opportunity Customer Vendor Prospect Project Sales order Purchase order Worker Service order Item Customer transaction Expense report line Expense report Vendor invoice Vendor invoice line Purchase order line Table smmLeadTable smmOpportunityTable CustTable VendTable smmBusRelTable ProjTable SalesTable PurchTable HcmWorker SMAServiceOrderTable InventTable CustTrans TrvExpLine TrvExpTable VendInvoiceJour VendInvoiceTrans PurchLine
Each case can have multiple associations and multiple associations of the same type. For example, a case related to a specific customer, could also be related to customer transactions.
3-38

Demonstration: Create a Case Association Entity Type
To create a new case association entity type, follow these steps. 1. Add a new element to the CaseEntityType base enum for the table that you want to relate to. In this example, Vehicles for Fleet management will be used. 2. Add a case statement to the smmAssociationLink.performLookup method for the new entity. Use the following code sample to guide you. case CaseEntityType::Vehicle: oSysTableLookup = SysTableLookup::newParameters(tablenum(FMVehicle), callerControl); oqbds = oQuery.addDataSource(tablenum(FMVehicle)); oSysTableLookup.addLookupfield(fieldnum(FMVehicle, VehicleID)); oSysTableLookup.addLookupfield(fieldnum(FMVehicle, VehicleModel)); oSysTableLookup.addLookupfield(fieldnum(FMVehicle, Description)); oSysTableLookup.parmQuery(oQuery); oSysTableLookup.performFormLookup(); break; 3. Add a case statement to the smmAssociationLink.performJumpRef method to open the main form for the new entity. Use the following code sample to guide you. case CaseEntityType::Vehicle: menuItemName = menuitemdisplaystr(FMVehicle); break; 4. Add a case statement to the smmAssociationLink.entityType2TableId method to specify the table number for the new entity. Use the following code sample to guide you. case CaseEntityType::Vehicle: tableId = tablenum(FMVehilce); break; 5. Add a case statement to the smmAssociationLink.entityType2FieldId method to specify the field number for the primary field on the entity. Use the following code sample to guide you. case CaseEntityType::Vehicle: fieldId = fieldnum(FMVehicle, VehicleId); break;
3-39

6. Add a case statement to the smmAssociationLink.entityType2FieldName method to specify the field number for the primary field on the entity. Use the following code sample to guide you. // Fleet management vehicle case tablenum(FMVehicle): returnValue = CaseEntityType::Vehicle; break; 7. Modify the CaseDetail form to add a "more information" group to the Case Association FastTab. o Add a data source to the form for the entity you want. In this example add the FMVehicles table. Make sure that you relate the table to the CaseAssociation data source on the form. o Create a new Group in the Group:Group_MoreInformation area of the TabPage:AssocitationsTabPage. Make sure that you auto declare the new group. Call the new tab page CaseMoreInformation_FMVehicles. o Add fields to the tab page from the data source. You can also choose to use a field group. For example, select the DetailsGroup in the DataGroup property of the new group. o In the showMoreInformation method on the form, declare a new boolean for your entity type. Use the following code sample to guide you. boolean showFMVehicle = (caseAssociation.EntityType == CaseEntityType::Vehicle); o In the showMoreInformation method on the form, add an OR statement to the boolean showMoreInformationGroup variable. Use the following code sample to guide you.
3-40

boolean showMoreInformationGroup = ( showTrvExpTable || showTrvExpTrans || showsmmLeadTable || showsmmOpportunityTable || showInventTable || showServiceOrderTable || showHcmWorker || showPurchLine || showPurchTable || showSalesTable || showProjTable || showsmmBusRelTable || showVendTable || showCustTable || showCustTrans || showVendInvoiceJour || showVendInvoiceTrans || showFMVehicle); o In the showMoreInformation method on the form, add an IF statement to make the new group visible when the case association record is for a vehicle. Use the following code sample to guide you.
if (caseMoreInformation_FMVehicles.visible() != showFMVehicle) { caseMoreInformation_FMVehicles.visible(showFMVehicle); FMVehicle_DS.refresh(); }
Demonstration: Use the New Case Association Entity Type

To test the new case association type, follow these steps. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Open Home > Area Page > Common > Cases > All cases. Click Case in the New group of the Action Pane. Select General > GEN1 in the Case category field. Click Create. Click No on the Create activity dialog box. On the Associations FastTab of the Case form, click Add. In the Entity type field, select Vehicle. In the ID field, select a vehicle. Save the record. Click the Details button. The Vehicles form should open to the vehicle you selected in step 7. Close all the forms.
3-41

Demonstration: Extend Cases to a Form
Once you have created a new case association entity, the cases can be created from any of the Cases list pages in the Home module. To add cases directly from a form, you must add a menu item button to the form that calls the CaseDetailFormCreate class. This class is designed to call the CaseDetailForm::writeCreateCase() method which creates a case and then calls the smmAssociationLink::createCaseAssociation(). This method creates a case association for the record that you have selected. To add the cases buttons to a new form, follow these steps. 1. Create a new Display menu item that calls the CaseDetailFormCreate class. View the CaseDetailNewSales for an example of this. 2. On the form where you want to add the buttons do the following. a. If a General tab does not exist on the Action Pane, add one. b. Add the menu item that you created in step 1 to the form. c. Add the CaseDetails menu item to the form. TIP: You can copy and paste the buttons from the SalesTable form onto the FMVehicle form.
3-42

Make sure that you specify an image resource, and set the data source property on both menu items. The Vehicle form should resemble the following figure when you are finished.
FIGURE 3.7 VEHICLE FORM
To test that the new buttons work correctly, follow these steps. 1. 2. 3. 4. 5. 6. 7. 8. Open Fleet management > Common > Vehicles > All vehicles. Select a vehicle. Click the General tab on the Action Pane. Click Create case. Select a Case category. Click Create. Click No on the Create activity dialog box. On the Associations FastTab, verify that an association is created for the vehicle that you created the case for. 9. Close the forms.
3-43
Lab 3.2 - Extend Case Management

This lab demonstrates how to extend case management to add a new case association entity type for rentals. This lab is designed for self-study. Completing this lab takes approximately 20 minutes. Scenario Vince, the Operations Manager, has noticed an increase in the number of calls and the issues when vehicles are rented and returned. He wants a way to record these issues when they are reported so that they can be followed up on. He has decided to start by using case management to help with this process. He wants to create cases for specific rentals to help control the return process for vehicles. The inspectors will then record information that is collected during the return such as the issues the customer had with the vehicle and the damage that is found on the vehicle when it is returned. So, Simon, the Business Systems Developer, must extend the case management framework to allow cases to be associated to rentals.
Challenge Yourself!
Use the information that is provided to add rentals as a case association entity type. Make sure that you add buttons on the Rental form to create the case and automatically add an association.
Need a Little Help?

1. Modify the CaseEntityType base enum. 2. Modify the following methods in the smmAssociationLink class. o performLookup o performJumpRef o entityType2TableId o entityType2FieldId o entityType2FieldName 3. Modify the CaseDetail form to add a "more information" group to the Case Association FastTab. 4. Test the new case association type by adding a case in the All cases list page in the Home module. 5. Add the cases buttons to the Rentals form. 6. Test the cases buttons on the Rentals form.
3-44

Step by Step
To create a new case association entity type, follow these steps. TIP: The code samples for this lab can be found in the AX2012_ENUS_DEVIV_03_02_LAB_CODE.txt file. You can copy and paste these code samples into the correct methods. 1. Add a new element to the CaseEntityType base enum for Rentals. 2. Add a case statement to the smmAssociationLink.performLookup method for the new entity. Use the following code sample to guide you. case CaseEntityType::Vehicle: oSysTableLookup = SysTableLookup::newParameters(tablenum(FMRental), callerControl); oqbds = oQuery.addDataSource(tablenum(FMRental)); oSysTableLookup.addLookupfield(fieldnum(FMRental, RentalID)); oSysTableLookup.addLookupfield(fieldnum(FMRental, Customer)); oSysTableLookup.addLookupfield(fieldnum(FMRental, Vehicle)); oSysTableLookup.parmQuery(oQuery); oSysTableLookup.performFormLookup(); break; 3. Add a case statement to the smmAssociationLink.performJumpRef method to open the main form for the new entity. Use the following code sample to guide you. case CaseEntityType::Rental: menuItemName = menuitemdisplaystr(FMRental); break; 4. Add a case statement to the smmAssociationLink.entityType2TableId method to specify the table number for the new entity. Use the following code sample to guide you. case CaseEntityType::Rental: tableId = tablenum(FMRental); break; 5. .Add a case statement to the smmAssociationLink.entityType2FieldId method to specify the field number for the primary field on the entity. Use the following code sample to guide you.
3-45

case CaseEntityType::Rental: fieldId = fieldnum(FMRental, RentalId); break; 6. Add a case statement to the smmAssociationLink.entityType2FieldName method to specify the field number for the primary field on the entity. Use the following code sample to guide you.
// Fleet management vehicle case tablenum(FMRental): returnValue = CaseEntityType::Rental; break; 7. Modify the CaseDetail form to add a "more information" group to the Case Association FastTab. a. Add a data source to the form for the entity you want. In this example add the FMRental table. Make sure that you relate the table to the CaseAssociation data source on the form. b. Create a new Group in the Group:Group_MoreInformation area of the TabPage:AssocitationsTabPage. Make sure that you auto declare the new group. Call the new tab page CaseMoreInformation_FMRental. c. Add fields to the tab page from the data source. You can also choose to use a field group. For example, select the DetailsGroup in the DataGroup property of the new group. d. In the showMoreInformation method on the form, declare a new boolean for your entity type. Use the following code sample to guide you. boolean showFMRental = (caseAssociation.EntityType == CaseEntityType::Rental); e. In the showMoreInformation method on the form, add an "or" statement to the boolean showMoreInformationGroup variable. Use the following code sample to guide you. boolean showMoreInformationGroup = ( showTrvExpTable || showTrvExpTrans || showsmmLeadTable || showsmmOpportunityTable || showInventTable || showServiceOrderTable || showHcmWorker || showPurchLine || showPurchTable || showSalesTable || showProjTable || showsmmBusRelTable || showVendTable || showCustTable ||
3-46

showCustTrans || showVendInvoiceJour || showVendInvoiceTrans || showFMRental); f. In the showMoreInformation method on the form, add an IF statement to make the new group visible when the case association record is for a vehicle. Use the following code sample to guide you.
if (caseMoreInformation_FMRental.visible() != showFMRental) { caseMoreInformation_FMRental.visible(showFMRental); FMRental_DS.refresh(); } To test the new case association type, follow these steps. Open Home > Area Page > Common > Cases > All cases. Click Case in the New group of the Action Pane. Select General > GEN1 in the Case category field. Click Create. Click No on the Create activity dialog box. On the Associations FastTab of the Case form, click Add. In the Entity type field, select Rental. In the ID field, select a rental. If there are no rentals, create one in the Rentals form. 9. Save the record. 10. Click the Details button. 11. The Rental form should open to the rental you selected in step 7. Close all the forms. To add buttons to the Rental form, follow these steps. 1. Create a new Display menu item that calls the CaseDetailFormCreate class. View the CaseDetailNewSales for an example of this. 2. On the FMRental form do the following. o o o If a General tab does not exist on the Action Pane, add one. Add the menu item that you created in step 1 to the form. Add the CaseDetails menu item to the form. 1. 2. 3. 4. 5. 6. 7. 8.
3-47

TIP: You can copy and paste the buttons from the SalesTable form onto the FMVehicle form. Make sure that you specify an image resource, and set the data source property on both menu items. TIP: You can import the AX2012_ENUS_DEVIV_03_02_LAB_SOL.xpo file to verify and compare your solution.
3-48
Policy Framework
Microsoft Dynamics AX 2012 introduces a policy framework that can be used to define policy rules in modules to help guide the flow of business. The framework provides a common pattern and rich feature set that users can take advantage of to enforce simple rules or to evaluate and act on several different rules in a complex organizational hierarchy. The actual rules used by businesses, and the actions that these rules allow, prevent, or alter are outside the scope of the framework. However, this white paper does provide examples of the policy types and rule types that that are included with Microsoft Dynamics AX 2012. NOTE: The policy framework is only used for defining and enforcing business rules. It is not related to the framework that creates extensible data security policies also being introduced in Microsoft Dynamics AX 2012. There are three perspectives from which the policy framework can be viewed and used, depending on the role of the user. A developer introduces the policy types and rule types to be evaluated. A software developer writes the logic that retrieves date-effective rules for a given user. It does this to enforce these rules as the module requires (for example, in form logic to allow or prevent certain actions).
NOTE: One person often performs the role of developer and software developer. An administrator, in a manager role, defines specific rule data that will be enforced.
Developers and administrators can use the policy framework to improve their business processes by enforcing rules for Microsoft Dynamics AX 2012 users. Examples of rules include the following. Expense reports submitted by employees for items above a certain currency amount are disallowed or result in an appropriate warning. Employees in one organization can view a specific procurement catalog while other employees (for example, those in a different country or region with different suppliers) are required to view a different catalog. Employees with a particular title can approve lines only up to a certain amount of currency. Documents must be validated against certain criteria, and violations of those criteria must be flagged.
3-49

For each of these cases, a developer specifies the type of data that is stored in the policy and how various forms and classes behave with that data. An administrator then defines and manages who the policies will affect (and when) and specifies the exact data values for each rule.
Framework Components
The policy framework consists of three main components that provide the functionality that corresponds to the developer and administrator roles described earlier. A unified, extensible schema that gives the developer a basic platform on which to build a policy solution. An Application Programming Interface (API) that provides developer with the way to retrieve policy rules. Policy rules take the developer directly to the data needed to execute the appropriate business logic. A common entry point for both the policy administrator and the developer, who can use it to manage policies. Little customization is required beyond entry of their business data.
These components provide the flexibility that developers and administrators must have to achieve their objectives without problems. They also give the user the same appearance and behavior as the rest of the policy user interface (UI) in Microsoft Dynamics AX 2012.
Policy Types
A policy type is a collection of all the rule types that apply to a given module or feature area. A user in a manager role can be granted permission to define policies of a given type through a menu item that opens a list page. The list page displays all the policies of a particular policy type. Microsoft Dynamics AX 2012 includes six policy types. These types are specified with the following SysPolicyTypeEnum enumeration values. ApprovalPolicy AuditPolicy PurchasingPolicy TrvExpensePolicy TrvRequisitionPolicy VendInvoicesPolicy
3-50

Each policy type is associated with a hierarchy purpose (specified in the HierarchyPurpose field in the SysPolicyType table) that defines the organizational hierarchies that can be assigned to these policies. For example, a developer can only assign organizations in the hierarchies that are designated for Procurement internal control to PurchasingPolicy policies. The same organizational hierarchy can be assigned to multiple hierarchy purposes.
Rule Types
Rules are at the core of any policy. The necessary data that defines how policies will be enacted is located in rules. After a developer defines policy types and rule types and he or she creates a policy, the policy administrator can add rules to that policy. For example, suppose that an administrator adds a catalog rule to a purchasing policy. The catalog rule is configured to specify the Adventure Catalog for internal procurement. After the purchasing policy is associated with a particular organization, all employees of that organization will see the Adventure Catalog when they browse the internal procurement site. Rules are date-effective, which gives you a set of powerful options for manipulating policy events over time. You can define rules that take effect in the present and expire sometime in the future, or that never expire. You can also set up rules that will take effect at some specified point in the future. By defining date-effective rules, you prevent multiple rules from being active at any given time, when they might provide conflicting data. After a rule has gone into effect, it can only expire or be discontinued. It can never be removed from the policy. This constraint provides enhanced auditing capability and historical policy retention. The policy framework can be queried for the rules that were in effect at a specific time, if it is necessary. As mentioned earlier, each rule is associated with a corresponding form. The developer implements the form, which displays and stores data in the data model. The administrator can then interact with this form to define and update the rule as needed.
Organization Assignment
Before a policy can affect anyone, it must be associated with an organization. The administrator configures the association with the organization on the SysPolicy form after a policy is created. In the business logic, the developer queries the API for rules that are in effect for a specific organization. All hierarchies with a specific hierarchy purpose can be sources from which to select organizations. An additional source from which to select organizations is the flat list of legal entities in the CompanyInfo table, which are designated in the policy framework as Companies. (An example would be a legal entity with a DataAreaId of DAT.) Although not a true hierarchy, this can be thought of as a default hierarchy type that is always available.
3-51

You can assign only organizations from a single hierarchy type to a given policy (this is the typical scenario). If organizations from multiple hierarchy types require the same policy, you must create multiple policies. For example, if you have to create an AuditPolicy policy for employees of organizations in a procurement hierarchy and for employees of companies in the flat list in Microsoft Dynamics AX 2012, you will have to create a separate policy for each group.
Policies Data Model

Before you start to develop policies, you should understand the underlying data model. There are only three core tables with which you have to be familiar. The SysPolicyRule table The SysPolicyType table The SysPolicyRuleType table
SysPolicyRule table
The SysPolicyRule table is the main table with which you will interact. To demonstrate the design options that this table allows, you start with the output and work backward. When you query the policy API (by using the SysPolicies::getPolicyRuleIds method) for a list of rules for a given policy type, rule type, and organization, the API returns an array of RecIds to the SysPolicyRule table, which holds a list of specific rule instances. With this strategy you can follow one of two general patterns shown for storing and accessing your rule data. Select the pattern that best suits your requirements. One set of data for each rule
This is the more common pattern. There is just one set of data for each rule, which is stored in one row in a table. To implement this pattern, create a table that is a subtype of the SysPolicyRule table and add all the fields required for your feature. A RecId that you receive from the policy API will now directly correspond to a date-effective row in your table (which is managed by the policy framework). You can directly query your table without having to know that it extends the SysPolicyRule table. You can view examples of this pattern in the CatCatalogPolicyRule and TrvPolicyRule tables. For more information, view the ER diagram.
3-52

Many entities for each rule
Use this pattern when you have to store several rows of information for each rule (meaning, the rules are displayed as a grid on the rule form). In this case, create a table with the fields that you must have that is not a subtype of the SysPolicyRule table. Instead, add a foreign key to the SysPolicyRule table to establish a many-to-one relationship. By doing this, you can reference many rows of data in your table with one SysPolicyRule RecId. You can view examples of this pattern in the ProcCategoryPolicyParameter and ProcCategoryAccessPolicyParameter tables.
3-53

SysPolicyType and SysPolicyRuleType tables The SysPolicyType and SysPolicyRuleType tables store the core type information that defines your policy and its rules. This information is static; therefore, after it is configured, the rows in these tables should not have to change, and no UI is provided for doing this.
FIGURE 3.8 POLICIES DATA MODEL
3-54

NOTE: This figure shows the key relationships among all the tables in the data model. None of the related tables will be directly queried. However, the diagram provides a good basis for understanding the entity relations involved in the policy framework.
Procedure: Create a Policy Type

To create a new policy type, follow these steps. 1. Open the Development Workspace. 2. In the AOT, right-click Data Dictionary > Base Enums > SysPolicyTypeEnum and then select New Element. 3. Enter a name and label for the element such as FleetManagemetPolicy or SalesPolicy. 4. Save the base enum. 5. Create a row for the new policy type in the SysPolicyType table. You can add a row to the SysPolicyType table in one of two waysupdate the SysPolicySetup class or write a simple job to insert the row.
Update the SysPolicySetup Class

To update the SysPolicySetup class, follow these steps. 1. 1. Open the Development Workspace. 2. 2. In the AOT, right-click Classes > SysPolicySetup and then click Edit. 3. In the Code Editor change the classDeclaration method by optionally adding a SysSetupConfigurationKeyAttribute for the configuration key that enables the functionality for your policy. 4. Create a new method for your policy type called load<PolicyTypeName>PolicyData. In this example the method would be called loadFleetManagementPolicyData. a. Add a line of code to the method to add the Fleet management policy type. SysPolicyType policyType = SysPolicySetup::addPolicyType(SysPolicyTypeEnum::FleetMan agementPolicy, HierarchyPurpose::PurchaseControl); NOTE: This example uses the PurchaseControl hierarchy purpose. If you have created a new hierarchy purpose, make sure that you select that purpose.
3-55

b. Later you will have to add a line of code for each rule type related to the policy type. The format is as follows. SysPolicySetup::addRuleType(policyType, SysPolicyRuleTypeEnum::<PolicyRuleName>, formstr(<PolicyRuleFormName>)); Where <PolicyRuleName> is the name of the policy rule enumeration value and the <PolicyRuleFormName> is the name of the form that you created for the rule type. NOTE: This step cannot be completed until after you have created rule types and forms for each rule type. 5. Modify the loadData method to call the method that you created in step 4. Optionally you can add an IF statement to only call the method if the configuration key is enabled. Because this class is an implementation of the SysSetup class, its loadData method (which fills the policy and rule type tables) is called on installation or upgrade of Microsoft Dynamics AX 2012, on activation of the configuration keys, and on full synchronizations of all the tables. You can also write a job to manually invoke the SysPolicySetup.loadData method. The only two required fields in the SysPolicyType table are PolicyType and HierarchyPurpose. The PolicyType field must match the value that you add to the SysPolicyTypeEnum enumeration. The remaining fields are optional settings.
Procedure: Add an Entry Point for the Policy

To create a basic working path for your new policy type, you have to add a menu item that points to the SysPolicyListPage form. You must set three properties on this menu item to filter to the new policy type. To create a new menu item, follow these steps. 1. Open the Development Workspace. 2. In the AOT, right-click Menu Items > Display and select New Menu Item. 3. In the Properties window, set the following values. o EnumTypeParameter = SysPolicyTypeEnum. o EnumParameter = The name of the new policy type (for example, TrvRequisitionPolicy) that has been added to the SysPolicyTypeEnum enumeration. o Parameters = An integer that represents the enumeration value of the new policy type (for example, 3). 4. Save the menu item.
3-56

Adding a new menu item also requires you to add the menu item to a menu and to a privilege. Knowledge of how to do this is assumed and is not discussed in this course.
Procedure: Create a Rule Type

The process for creating new rule types resembles the process for creating a new policy type. You have to perform the same two basic stepsadd rows in the table, and add new enumerations (if the rule types are known). In this example, it is assumed that your rule types are static and known at design time. If your requirements require that the rule types must be dynamic (meaning that is defined by the user) and added at run time, refer to the SysPolicySourceDocumentRuleType form in the AOT for an example of this pattern. To add rule types to the SysPolicyRuleType table, edit the SysPolicySetup class by completing step 4.b. in the Create a Policy Type procedure for each rule type. There are several instances of this procedure in the class code that you can follow as examples. NOTE: This step cannot be completed until you have created a form for each rule type. The required fields are as follows: Name: Should match the name of the enumeration that is added. PolicyType: A foreign key to the SysPolicyType table. RuleFormName: The AOT form name of the form that will be launched when configuring a rule of this type. For more information, refer to the Creating rule forms section later in this training material. IncludeParentRules: A flag that enables the IsInherited flag on rule instances. This flag is usually set to Yes so that rules can be set at a parent organization level to affect all organizations below it in the hierarchy. IsPrecedenceSupported: A flag that tells the framework whether the hierarchy precedence for a policy type can be overridden at a rule-type level.
3-57

Procedure: Create Rule Forms
To allow an administrator to fill your rule table with data, you must create a form that displays and saves that data. The name of the form or menu item pointing to that form is stored in the RuleFormName field of the SysPolicyRuleType table. The only data that you are required to show on this form are the effective date (which defaults to the current date and time) and the expiration date (which defaults to Never). These dates are stored in the ValidFrom and ValidTo fields in the SysPolicyRule table. The basic flow of this form is that, when it is opened, it shows either the values of the rule that is currently open or the default values to use when creating a new rule. When the user closes the form, the appropriate records should be saved to the SysPolicyRule table and to any other tables that are used to store your rule data. Several of these forms are included with Microsoft Dynamics AX 2012. Because forms are feature-specific, more precise guidance cannot be provided about how to design them. We recommend that you view the forms listed in the RuleFormName column of the SysPolicyRuleType table for examples. The following figure shows the CatCatalogPolicyRule form. It is the simplest example because it contains just one piece of data for each rule.
FIGURE 3.9 CATALOG POLICY RULE FORM
Procedure: Retrieve Date-Effective Rules

When rules are defined and are in effect in the system, your application logic can query for these rules and take appropriate action. The SysPolicies::getPolicyRuleIds method is provided to make this process easier. At a minimum, this method must be passed the policy type and the rule type that you set up earlier, and the organization that you want to check for rules. The method returns references to the SysPolicyRule table for the rules that are active in the specified organization. From there, querying for the needed values in the table that you added (which can be either a subtype of, or contain a foreign key to, the SysPolicyRule table) will depend on your business logic. Refer to the XML documentation for a complete, up-to-date description of the getPolicyRuleIds method.
3-58

After the developer has finished setting up the policies, a policy administrator can configure policies as required by their business needs.
Summary
The Application Foundation Features chapter reviewed several features that are used throughout the system. The global address book is a central repository for addresses and contact information. You can extend the global address book framework to create new party types. You can also use the extensible data security policy framework with the global address book framework to help secure address information across legal entities, or teams, or both. Developers and administrators can use security policies to block access to subsets of data rows in tables. A policy resembles a where clause in an SQL select statement. A security permission increases the access a user has to data, but a security policy decreases access to data. You can use financial dimensions to create "attributes" that you can use as account segments for a shared chart of accounts. There are two basic types of financial dimensions. The organization model represents internal control, data security access, and performance reporting structures designed to divide responsibility for human and operations resources and work processes. The organization model in Microsoft Dynamics AX 2012 introduces two new conceptslegal entity and operating unit. You can extend the organization model framework to create new types of operating units or new purposes for a hierarchy. Case management provides the tools to handle issues more quickly and improve customer, employee, and vendor relationships. You can extend the case management framework to work with any data entity. Microsoft Dynamics AX 2012 introduces a policy framework that is used to define policy rules in modules to help guide the flow of business. The framework provides a common pattern and rich feature set that users can take advantage of to enforce simple rules or to evaluate and act on several different rules in a complex organizational hierarchy. You can extend the policy framework to create new policy types or new policy rule types.
3-59
Test Your Knowledge

Test your knowledge with the following questions. 1. Which class is used to implement a single address on a form? ( ) DirUtiltity ( ) DirPartyLookup ( ) LogisticsEntityPostalAddressFormHandler ( ) LogisticsMultiEntityPostalAddressFormHandler 2. Which of the following are valid types of operating units that are available out of the box? (Select all that apply) ( ) Department ( ) Cost Center ( ) Legal Entity ( ) Business Unit 3. Fill in the blanks with the name of the table that best describes the content of the table to test your knowledge of this section. Stores a reference to each record that a case is related to. _____ Stores the log entries related to each case. _____ The primary table for storing all cases. _____ Stores the parent child relationship between cases when a case is related to another case. _____ 4. Put the following steps in order: Step: _____: Review the entity to add a policy to. _____: Add table constraints. _____: Test the security policy. _____: Create a new security policy. _____: Create a new query. _____: Set the context type and role.
3-60

5. Which of the following classes are used to add financial dimension controls to a form? (Select all that apply) ( ) FinancialDimensionAccountController ( ) FinancialDimensionDefaultAccountController ( ) LedgerDimensionAccountController ( ) LedgerDimensionDefaultAccountController 6. Categorize the following items: _____ 1. A person or organization. _____ 2. A group of parties. _____ 3. Entities that refer to customers, vendors, competitors, workers, applicants, and so on. _____ 4. Entities that refer to inventory, bank groups, bank accounts, and so on. _____ 5. Refers to either a postal address or an electronic address such as email, telephone or fax. a. Address book b. Non-party entities c. Location d. Party e. Party roles
7. List the four basic steps for creating a new operating unit type.
8. Describe what "trimming" is.
3-61
Quick Interaction: Lessons Learned

Take a moment and write down three key points you have learned from this chapter 1.
2.
3.
3-62
Solutions
Test Your Knowledge
1. Which class is used to implement a single address on a form? ( ) DirUtiltity ( ) DirPartyLookup () LogisticsEntityPostalAddressFormHandler ( ) LogisticsMultiEntityPostalAddressFormHandler 2. Which of the following are valid types of operating units that are available out of the box? (Select all that apply) () Department () Cost Center ( ) Legal Entity () Business Unit 3. Fill in the blanks with the name of the table that best describes the content of the table to test your knowledge of this section. Stores a reference to each record that a case is related to. Stores the log entries related to each case. The primary table for storing all cases. CaseLog CaseAssociation
CaseDetailsBase
Stores the parent child relationship between cases when a case is related to another case. CaseDependancy 4. Put the following steps in order: Step: 1 4 6 3 2 5 : Review the entity to add a policy to. : Add table constraints. : Test the security policy. : Create a new security policy. : Create a new query. : Set the context type and role.
3-63

5. Which of the following classes are used to add financial dimension controls to a form? (Select all that apply) ( ) FinancialDimensionAccountController ( ) FinancialDimensionDefaultAccountController () LedgerDimensionAccountController () LedgerDimensionDefaultAccountController 6. Categorize the following items: d 1. A person or organization. a 2. A group of parties. e 3. Entities that refer to customers, vendors, competitors, workers, applicants, and so on. b 4. Entities that refer to inventory, bank groups, bank accounts, and so on. c 5. Refers to either a postal address or an electronic address such as email, telephone or fax. a. Address book b. Non-party entities c. Location d. Party e. Party roles
7. List the four basic steps for creating a new operating unit type. MODEL ANSWER: Define a new Base Enum value for the OMOperatingUnitType that corresponds to the new type of operating unit. Define a query OMStoreQuery for the new type of operating unit. Define a view OMStoreView based on the OMStoreQuery query. Optionally, define a new menu item that corresponds to this operating unit to create new instances of this type of operating unit. 8. Describe what "trimming" is. MODEL ANSWER: The security configuration of each field is assessed for the current user. This security behavior is called field trimming because the restricted fields are trimmed out of the results before the results are sent from the AOS to the client.
3-64

Ax2012 Enus Deviv 03 PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ax2012 Enus Deviv 03 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Chapter 3: Application Foundation Features

CHAPTER 3: APPLICATION FOUNDATION FEATURES

Development IV in Microsoft Dynamics AX 2012

Global Address Book

Benefits and Features

Chapter 3: Application Foundation Features

Development IV in Microsoft Dynamics AX 2012

FIGURE 3.1 CORE PARTY AND ADDRESS BOOK DATA MODEL

Chapter 3: Application Foundation Features

FIGURE 3.2 LOCATION DATA MODEL

Development IV in Microsoft Dynamics AX 2012

Chapter 3: Application Foundation Features

dirPartyLookupEntitiesFilter); return ret; }

Adding an Address to an Entity

Development IV in Microsoft Dynamics AX 2012

Procedure: Add a Single Address to an Entity

b. Add a form method called getAddressController.

Chapter 3: Application Foundation Features

c. Override the main data source active method.

Procedure: Add Multiple Addresses to an Entity

Development IV in Microsoft Dynamics AX 2012

b. Add a form method called parmPostalAddressLocation.

c. Override the main data source active method.

d. Add LogisticsEntityPostalAddressView as a data source and override the executeQuery method.

Chapter 3: Application Foundation Features

Global Address Book Security

Development IV in Microsoft Dynamics AX 2012

Extensible Data Security Policy Framework

FIGURE 3.3 CONCEPTUAL MODEL OF EXTENSIBLE DATA SECURITY

Chapter 3: Application Foundation Features

FIGURE 3.4 VENDPROFILEACCOUNTPOLICY QUERY

Development IV in Microsoft Dynamics AX 2012

FIGURE 3.5 VENDPROFILEACCOUNT SECURITY POLICY

Chapter 3: Application Foundation Features

Development IV in Microsoft Dynamics AX 2012

Chapter 3: Application Foundation Features

Development IV in Microsoft Dynamics AX 2012

Inspect that Data You Want to Help Secure

Create a Query for Your Security Policy

Create a Security Policy

Chapter 3: Application Foundation Features

Verify that the Security Policy is Enforced

Demonstration: Constrain Access to Related Tables

Development IV in Microsoft Dynamics AX 2012

Chains of Constrained Tables in a Policy

Constrain Views by the Policy

Chapter 3: Application Foundation Features

Demonstration: Add Role Context to a Security Policy

Change the Security Policy to Specify a Security Role

Verify that the Security Policy is Enforced

Development IV in Microsoft Dynamics AX 2012

Lab 3.1 - Extensible Data Security Policies

Need a Little Help?

Chapter 3: Application Foundation Features

Create a Security Policy

Development IV in Microsoft Dynamics AX 2012

Specify a Security Role

Chapter 3: Application Foundation Features

Financial Dimension Framework

Dimensions in the System

Development with the Financial Dimension Framework

Development IV in Microsoft Dynamics AX 2012

Organization Model Framework