Installing Workflow in Ax 2009

Hi friends,

Today we are going to install the workflow and configure it in AX 2009

Open Administration => Security => SystemServiceAccounts.

In System service Accounts you will find alias Name(Proxy Account) and Network Domain.Enter Workflow system Account and

Workflow Execution Account.

Note : Have Admin rights before installing workflow

1. Install the workflow as per the wizard

2.It will ask for .Net Business Connector Proxy Account password.

3.After that it will ask credentials for either put proxy account it is in another network put Domain\computerName$

4.Finish the installation.

Here come the part of making the workflow Url valid.

1. Open IIS Manager settings.

2.If you install workflow in you will see the workflow installed in Default site.

Note :: If windows Share point servives or share point server is running on the site then workflow cannot execute in that port.

You have to create a new website and new port and add an exception to the port.

3. In Application pool => click Advanced settings keep the following properties

.NetFrameWork = 2.0

Enable32BitApplications => true

4. In Defalut website click MicrosoftSynamicsAXWorkflow50

Authentication => AnonymousAuthentication => Enabled and click edit and keep AppPoolIdentity to everyone(:: error 401)

Directory Browsing => enable it (::error 405)


5. Check whether the workflow is running correctly or not by browsing.

6. In Administration => setup => workflowInfastructureAndConfiurationWizard run it and define the workflow group and set the

time interval for it.

By this workflow is ready to use .

Vivek Chirumamilla

Adding a range in Data Set in AX 2009

Hi friends,

Today we are going to add range in a Dataset.

A data set, typically used to access data for Enterprise Portal, can have one or more data sources from which data is accessed. You can use X++ code to add a range that restricts the data that is accessed by the data source. The code that adds the range must be written correctly so that only the data in the range is accessed.

Adding a Range:

To add a range for the data source that is used by a data set, you must override the init method for the data source. In this method, create a QueryBuildRange object that defines the range and specifies the values allowed. To prevent the range from being changed or removed, set the range status to hidden. This last step is very important to prevent data outside the range from being accessed.

The following example sets a range for the ContactPerson data source in the EPCustTableInfo data set. The range prevents rows from being accessed that have empty values in the ContactPerson or CustAccount fields. The status of the range is set to hidden to make sure that the range cannot be changed or deleted.

public void init()
{
QueryBuildRange rangeCustAccount;
super();

rangeCustAccount = this.query().dataSourceTable(tablenum(ContactPerson)).addRange(fieldnum(ContactPerson, CustAccount));
rangeCustAccount.value(SysQuery::valueNotEmptyString());
rangeCustAccount.status(RangeStatus::Hidden);
}





Vivek Chirumamilla

Inventory Dimensions In Ax 2012

Hi friends,

Today we have Inventory Dimensions

Inventory Dimensions are classified into 3 groups

Product :: Color,Size,Configuration.

Storage :: Site, Warehouse,Location,Pallet Id.

Tracking :: Batch number , Serial number.

The Configuration technology field specifies which type of product configuration, if any, will be applied to the newly created product.

Predefined variant - This type should be chosen if the product will not be configured, but simply rely on the user’s choice of Color, and/or Size, and/or Configuration for each transaction

Dimension-based configuration - This type should be chosen if the user will build a configurable BOM that relies on configuration rules to build the Config ID and the BOM lines. (This technology may only be chosen if Configuration is active on the Product dimension group selected for the product)

Rule-based configuration - This type should be chosen if the product will use Product builder

Constraint-based configuration - This type should be chosen if the product will use the new AX 2009 Constraint based product configuration method. (This technology may only be chosen if Configuration is active and is the lone Product dimension active for the Product dimension group selected for the product)

In Ax 2012 we have two types of items Products and product Masters, Product dimension group can only be selected to Product Masters.

Product Dimensions:

Navigate to Product information management -> Setup -> Dimension groups -> Product dimension groups.

Click on ‘Active’ check box beside the Product dimension you want to as shown in the above figure to activate the Product Dimensions

Storage Dimensions:

Navigate to Product information management -> Setup -> Dimension groups -> Storage dimension groups.

To make Site a mandatory, then select Mandatory check box.

· To make Primary stocking active for Sitethen select the ‘Primary stocking’ check box.

· To activate a dimension select ‘Active’ check box for that particular dimension.

Tracking Dimensions:

Navigate to Product information management -> Setup -> Dimension groups -> Tracking dimension groups.

To activate serial number control (a unique serial number can only be entered) select ‘Serial number control’ check box.


Assigning the Dimension groups to a new product of type Product Master:

To create a product for a single company or entity go to Product information management -> Common -> Released products.

· Click the Product -> New -> Product button.

To Assign Tracking and Storage Dimension Groups click the Product -> Set up -> Dimension group button.

To Assign Product dimensions

· As we have only selected Configurations and size in the Product Dimension Group, we can only see these two Dimensions in the Product Dimension form.

· Now click on ‘New’ Button to create a new configuration.

· Enter the Configuration and description of that particular configuration.

· Click on ‘size’ to create ‘Size’ dimension option

· Follow the same procedure followed for Configuration creation to create new ‘Sizes’.


Creating Product Variants::

· In AX 2009, there is a concept called Item Dimension combinations. An item must have item dimension combinations created in order to process items with item dimensions. The same concept is renamed as Product Variants in AX 2012.

· To create Product Variants for a product go to Released Product form ->Product Tab -> ‘Product master’ action group -> ‘Released product variants’ button.

· Clicking on the Variant suggestions button will show all the possible combinations of Configurations and Sizes.

· Click the Select all button to select all the combinations or else you can select required combinations and then click on Create button.

· All the Product Variants are created. Now Close the Released product variants form.




Vivek Chirumamilla

How to Add Dimension In Ax 2012

Hi friends ,

Today we are going to add dimension in Ax 2012

You can add dimensions to Microsoft Dynamics AX. The product ships with three dimensions: Department, Cost center, and Purpose.

Dimensions are based on extended data types that are defined as arrays. The extended data types with dimension information are as follows:

Dimension

DimensionAllocation

DimensionCriteria

DimensionKeepFromTransaction

DimensionLedgerJournal

MandatoryDimension


ADD A DIMENNSION::

1.In the Application Object Tree (AOT), add a new array element for the dimension to each extended data type listed above.


2.Associate the new array element with certain dimension table fields by doing the following for the Dimension and DimensionCriteria extended data types.

a.Click the extended data type, and then click the new array element.

b.Right-click Relations, and then click New > Normal to add a normal relation.

c.Right-click the relation, and then click Properties.

d.Set the Table property to Dimensions, and then set the RelatedField property to Num.

e.Right-click Relations, and then click New > Related field fixed to add a related field fixed relation.

f.Right-click the relation, and then click Properties.

g.Set the RelatedField property to DimensionCode.

3.Add a new value to the SysDimension enumeration that represents the new array element by doing the following.

a.Click Data Dictionary > Base Enums, right-click the SysDimension, and then click New Element.

b.Right-click the new element, click Properties, and then modify the Name property.

c.Modify other properties, as needed.

4.Create a relationship between the LedgerJournalTrans table and the Dimension table by doing the following.

a.Click Data Dictionary > Tables > LedgerJournalTrans, right-click Relations, and then click New Relation.

b.Right-click the new relation, and then click Properties.

c.Set the Table property to Dimensions, and set the Name property to InterCoDimension to distinguish it from other InterCoDimension relations on the LedgerJournalTrans table.

d.Add a related field fixed relation and two normal relations to the InterCoDimension relation, as shown in the following example.

5.Modify the LedgerAllocation form to display the new dimension by doing the following.

a.Right-click the LedgerAllocation form, and then click Compile.

b.Locate the following group controls in the TabPage:Dimension control, set the AutoDataGroup property for each group control to No, and then save the changes.

Group:FromDimensionNo

Group:SelectionCriterion

Group:To

Group:KeepTransactionDimension

The system automatically adds a new control to each group control that corresponds to the array element that you added to the extended data types in step 1.



Vivek Chirumamilla

Primary Index In Ax 2012

Hi friends,

A primary key is one type of key. The other type of key is an alternate key. There is a maximum of one primary key per table, whereas a table can have several alternate keys. The primary key is usually the type of key that other tables, called child tables, refer to when a foreign key field in those other tables need a relational identifier.

Starting in Microsoft Dynamics AX 2012 the primary key for every new table is always enforced by an index that has exactly one field. The one field is usually an incremented number or a completely meaningless number that is generated by the system. For new tables the default is a primary key based on the RecId field. This is represented as the surrogate key in the user interface.

The following describes the PrimaryIndex property and other that are related to keys.



PrimaryIndex

The drop-down list contains the surrogate key plus every index on the table that has its AlternateKey property set to Yes.

Vivek Chirumamilla

Dynamics AX Caching in Ax 2009

Cache Location

Caches are used on both the client and the server. The Microsoft Dynamics AX runtime manages the cache by removing old records when new records are added to the cache.

Client Cache

A client-side cache can be used only by the client. The client cache is used when a select is executed from the client tier. If no record is found in the client cache, the client then searches the server cache for the record. If the record isn't located in the server cache, it's retrieved from the database. The maximum number of records maintained in a client cache is 100 records per table for a given company.

Server Cache

A server-side cache can be used by any connection to the server. The server cache is used when a select is executed on the server tier. If no record is found in the cache, it's retrieved from the database. The maximum number of records maintained in a server cache is 2,000 records per table for a given company.

Record Caching

Microsoft Dynamics AX database record caching is a performance-enhancing feature that helps avoid database access when it's not strictly necessary. Retrieving database records from memory instead of the database significantly speeds up data access. Caching can reduce the performance penalty for repetitively accessing the same database records.

Types of Caching

Caching is transparent to the application; however, it's important to know how caching works to optimize its performance in Microsoft Dynamics AX. Following are the types of caching:

Single-record
Set-based
Single-record caching has the following characteristics:

Defined at design time
Moves records to the cache based on the table's CacheLookup property and the type of SELECT statement that is used to retrieve the record


Set-based caching has the following characteristics:

Defined either at design time or in X++ code
Moves sets of records to the cache
Implemented either through the table's CacheLookup property or in code by using the RecordViewCache class
Single-Record Caching

Record caching is enabled for a table when all the following statements are true:

The CacheLookup property on the table is enabled by setting it to one of the following values:
· notInTTS
· Found
· FoundAndEmpty

The table's PrimaryIndex property is set to a unique index that exists on the table. The RecId index does not qualify as a caching index unless you set the table's PrimaryIndex property to this index.
The record buffer disableCache method has not been called with a parameter of true.
The fields in the table's unique index make up the caching key. A record is placed in the cache when the following criteria are met:

The table is cached by setting the CacheLookup property to notInTTS, Found, or FoundAndEmpty.
The SELECT statement that selects the records uses an equal operator (==) on the caching key. The fields in the WHERE clause of the SELECT statement match the fields in the index referenced by the table's PrimaryIndex property.
The table's CacheLookup property defines how and when records are cached as shown in the following table.

CacheLookup Property Value

None

No data is cached or retrieved from the cache for this table.
This property value should be used for tables that are heavily updated or where it's unacceptable to read outdated data.
NotInTTS

All successful caching key selects are cached.
When in a transaction (after ttsBegin), no caches made outside the transaction are used. When inside a transaction, the record is read once from database and subsequently from cache. The record is select-locked when read in a transaction, which ensures that the record cached is not updated while the transaction is active.
A typical example of the NotInTTS property is the CustTable in the Microsoft Dynamics AX standard application. It's acceptable to read outdated data from the cache outside a transaction, but when data is used for validation or creating references, it is ensured that the data is real-time.
Found

All successful caching key selects are cached. All caching key selects are returned from the cache if the record exists there. A selectforUpdate in a transaction forces reading from the database and replaces the record in the cache.
This is typically used for static (lookup) tables, such as Unit, where the record usually exists.
FoundAndEmpty

All selects on caching keys are cached, including selects that are not returning data.
All caching key selects are returned from caching if the record exists there, or the record is marked as nonexistent in the cache. A selectforUpdate in a transaction forces reading from the database and replaces the record in the cache.
An example of FoundAndEmpty record caching is in the Discount table in the Microsoft Dynamics AX standard application. By default, the Discount table has no records. By using a FoundAndEmpty cache on this table, the keys that are queried for but not found are stored in the cache. Subsequent queries for these same non-existent records can be answered from the cache without a round trip to the database.
EntireTable

Creates a set-based cache on the server. The entire table is cached as soon as at least one record is selected from the table.


The Found and FoundAndEmpty caches cross transaction boundaries. The NotInTTS cache is newly created inside a transaction. This example, modified for the purposes of this topic, demonstrates how records are retrieved from the cache when the table's CacheLookup property is set to NotInTTS, and the PrimaryIndex property is set to a unique index on the AccountNum field.

static void NotInTTSCache(Args _args)
{
CustTable custTable;
;
// The query looks for records in the cache.
// If records don't exist, the query accesses the database.
select custTable
where custTable.AccountNum == '4000';
// The transaction starts.
ttsbegin;
// The cache is not used. The query accesses the database
// and records are placed in the cache.
select custTable
where custTable.AccountNum == '4000';

// The query uses the database because
// the forupdate keyword is used.
select forupdate custTable
where custTable.AccountNum == '4000';
// The query uses the cache and not the database.
select custTable
where custTable.AccountNum == '4000';
// The query uses the cache because
// the forupdate keyword was used previously.
select forupdate custTable
where custTable.AccountNum == '4000';

// The transaction is committed.
ttscommit;

// The query will use the cache.
select custTable
where custTable.AccountNum == '4000';
}
If the table CacheLookup property was set to Found or FoundAndEmpty, the first select statement inside the transaction (after the TTSBegin statement) would retrieve the record from the cache.

Set-Based Caching

In Microsoft Dynamics AX, groups of records can be cached all at once with set-based caching. Set-based caching can be implemented in two ways:

At design time, by setting the table's CacheLookup property to EntireTable.
In code, by using the RecordViewCache class.

EntireTable Cache

When you set a table's CacheLookup property to EntireTable, all the records in the table are placed in the cache after the first select. This type of caching follows the rules of single record caching in which the SELECT statement WHERE clause fields must match those of the unique index defined in the table's PrimaryIndex property.

The EntireTable cache is located on the server and is shared by all connections to the Application Object Server (AOS). If a select is made on the client tier to a table that is EntireTable cached, it first looks in its own cache and then searches the server-side EntireTable cache. An EntireTable cache is created for each table for a given company. If you have two selects on the same table for different companies the entire table is cached twice.

Joins that include an EntireTable cached table are only performed against the cached copy when all tables participating in the join are EntireTable cached. Otherwise a database join is performed.

Important Note:

Avoid using EntireTable caches for large tables because once the cache size reaches 128 KB the cache is moved from memory to disk. A disk search is much slower than an in-memory search.

Flushing the Cache

An EntireTable cache is flushed whenever an insert, update, or delete is made to the table. At the same time, the AOS notifies other AOSs that their caches of the same table must be flushed. After the cache is flushed, a subsequent select on the table causes the entire table to be cached again. Therefore, avoid caching any table that's frequently updated. Regardless of when updates are made, EntireTable caches are flushed every 24 hours by the AOS.

RecordViewCache Cache

Set-based caching is implemented in code by using the RecordViewCache class. You must first create a record buffer using the nofetch statement and then pass the record buffer to the RecordViewCache class when it's instantiated.

The cache is created on the server and is only accessible by the process that creates the cache object. Once the cache is instantiated, all select statements are issued against the cache, as shown in the following

static void RecordViewCache(Args _args)
{
CustTrans custTrans;
RecordViewCache recordViewCache;
;
// Define records to cache.
select nofetch custTrans
where custTrans.AccountNum == '4000';

// Cache the records.
recordViewCache = new RecordViewCache(custTrans);

// Use cache.
select firstonly custTrans
where custTrans.AccountNum == '4000' &&
custTrans.CurrencyCode == 'USD';
}


Due to concurrency issues, the forUpdate keyword on the instantiating X++ SELECT statement should only be used when all of the records in the result set will be updated. Otherwise it's a better strategy to use select forUpdate only for the records that are to be updated.

The RecordViewCache class is used in a select when the select is from a table that's cached, the select statement doesn't participate in a join and the select WHERE clause matches the WHERE clause with which the RecordViewCache was instantiated.

The cache created by the RecordViewCache class stores records in a linked list. Therefore Microsoft Dynamics AX searches the cache sequentially for records that match the search criteria. If the SELECT statement contains an ORDER BY clause, a temporary index is placed on the cache and the runtime uses the index when searching records.





Vivek Chirumamilla

Cross Comapany support in Ax 2009

Hi friends,

Today we have cross company support functionality published in the below post

static void Test(Args _args)
{
InventTable inventTable,inventTable1;

str Item;

str ItemName;

int ItemInt,ItemInt1,value,i;

container conCompanies = [ 'CEU', 'CEE' ];
;

select firstonly ItemId from inventTable1 order by ItemId;
Item = inventTable1.ItemId;


// While select ItemId from inventTable order by ItemId
while select
crossCompany
: conCompanies
ItemId from inventTable
order by dataAreaId,inventTable.ItemId
{

ItemName = inventTable.ItemId;

if(Item != ItemName)
{

ItemInt = str2int(ItemName);

ItemInt1= str2int(Item);

value = ItemInt - ItemInt1;

for(i=1;i {
ItemInt1 = ItemInt1 + 1;
info(int2str(ItemInt1));
}
Item = inventTable.ItemId;
}

}

}

Vivek Chirumamilla