AX : Work flow in Ax 2012

Few days back I got a chance to work on Ax2012 work flow, so I decided to document it for future reference and other user can also have an idea about it so here we start with what the work flow is.

What is Work flow :  A workflow represents a business process. A workflow defines how a business document flows through the system by indicating who must process and approve it.

Life Cycle:  Developer design the workflow based on customer requirements

System administrator configures the workflow.

End user run the workflow.

Bird's-eye view  :

Artifacts:

Work flow is revolve around the following artifacts 

•          Workflow query
•          Workflow category
•          Workflow type
•      Workflow approval 
•      Enabling workflow on a form
•      Work flow Configuration 

      Scenario : 
     scenario I need to implement work flow is :Create a custom document for submitting travelling allowance.
We Need to Cater Following Conditions in it

Assign workflow to If total amount is Less than $2500 than Line Manager Approval Required.

If Total Amount > 50,000 CFO Approval is required

If Amount > 1 Lac CEO Approval is required

Submitter can submit the workflow, approver can approve / Reject / Cancel the workflow.

TO implement above scenario I have taken / performed following task In order to accomplish it

Challenge:

If HOD of worker exists than it will go to HOD for Approval. Work flow will never through error in any case 

First thing First

Query

We must first create a query that will access the table fields for the workflow document. As shown in below image.

Category :

A workflow category is used to determine the module in which the workflow will

Be available. Refer to the image below

Type: It is the basic building block that can be used to create customized workflows that enforce business policies. A Work Flow type defines :

The Work Flow document to use.

Tasks and approvals that can be configured by the User.

Workflow categories used to assign a workflow type to a specific module.

Example of Work flow Type Properties is shown below

Approval :

Approvals are specialized workflow elements designed to support approval scenarios. Approvals have a set of fixed outcomes that the workflow supports. These outcomes are as follows:

§   Approve - Outcome type Complete.

§   Reject - Outcome type Return to the originator of the workflow.

§   RequestChange – Outcome type Change Requested to a specific person in the workflow process.

Example of Work Flow Approval is as shown in below image 

Enabling Work flow on Form:

Design:

Workflow Condition:

Important thing to remember:

Note there is a form named as “Tutorial_WorkflowProcessor” we Need to Start it while submitting / or taking any action on workflow Refer to below Image

Development Aspects:

Common Tables Involve in workflow development like if we want to get below information

Get Approval Date

 Get Approver Name

• WorkflowTrackingStatusTable   
• WorkflowTrackingTable;
• WorkflowVersionTable
• WFElementTble
• WFStepTable 

AX : XDS Extensible Data Security frame work

In this Blog post we will learn about Extensible Data Security frame work and how to implement security using XDS in ax 2012

What is XDS :

Extensible Data Security (XDS) is a framework in MicrosoftDynamics AX that allows developers and system administrators to deny access to subsets of data and only share a subset of data with appropriate users. XDS replaces the Record level security framework in previous MicrosoftDynamics.

XDS Artifacts

•       Query

•       Primary Table

•       Constrained Table

•       Policy

•       Context

Primary table: This is the main table in the query on which the policy is imposed. In our case, cust table is the primary table where we have to define the said range.

Constraint table: These tables have foreign key relation on the primary table and their contents will be secured based on range defined in primary table.  In our case, it will be Sales table where the customer display will be limited to the values defined in primary table.

•       Policy query: Every XDS policy has a query where the constraints (ranges) are defined. You can nest multiple data sources in the query.

Policy Context: Context type in the policy. It can be one of the following – Role Property/ Role Name/Context string.

Context String: You specify a value here and this will be matched with the Context string property defined for a role.

Role Name: This specifies the role for which the policy is applied.

Role property: This is used in combination with ContextString to specify multiple roles context.

Scenario:

Lets take a scenario in which we need to restrict user that it can only view the specific customer group sales Order. Let say cust group 20.

To implement the scenario follow the following steps

Step 1 : Create Query:

First thing first, Create AOT Query  with CustTable as a datasource of our Query as Shown in Figure (a)

 Figure (a)

Step 2 : Create Role

Create Role from AOT > Security > Roles, Specify the Label and description of created Role as shown in below image

Step 3 :  Create Policy

Now create policy and specify all the relevant properties as shown in figure (c). note:  do not leave any essential property blank here as these are very crucial in implementing XDS

Essential Properties of Policy are:

i)                    Primary Table  : in Our scenario its custTable

ii)                   Constrained Table : Select it as Yes or Leave it No according to your Requirement

iii)                 Context Type : select RoleName here

iv)                 RoleName : Select Role created in Step 2

Step 4 : Assign XDS Role to User

Assign XDS Role Created in step 2 to any user in which you need to test XDS. Refer to the below image 

Step 5 : Execution

When Login through a user which we have assigned our created XDS Role you will get the only customer record having custgroup = 20 as shown in below image