About action messages [AX 2012]Applies To: Microsoft Dynamics AX 2012 R3, Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012An action message is a system-generated suggestion to change an existing planned order. Action messages are generated by the master scheduling calculation in response to changedrequirements. For example, the due date or quantity may have changed because an order was firmed. You decide whether to make the changes that are suggested.You can configure how action messages are calculated for a coverage group that you attach to an item.

Selecting action messagesIn the Coverage groups form, you can select the action messages that you want the system to generate, and the coverage groups or items that the messages apply to. You can select the following action messages.

Message Description

Advance One or more planned orders should be moved forward in time. If you select this message, in thespecify the maximum number of days between orders that are advanced.

Postpone One or more planned orders should be postponed. If you select this message, in the Postpone marginmaximum number of days that are permitted between orders that are postponed.

Decrease Production orders, purchase orders, and other receipt transactions should be decreased to prevent excess inventory levels.

Increase Production orders, purchase orders, and other receipt transactions should be increased to prevent shortages in inventory.

Derived actions

Actions that are derived from requirements can be transferred to component items.

Configure Message Queuingto work with Microsoft Dynamics AXDynamics AX 4.0

An adapter for Microsoft Message Queuing (also known as MSMQ) is included with your Microsoft Dynamics AX installation.

Important

To send documents using MSMQ, you must use a domain account for the AOS account. For more information, see(AOS) instance.

To send documents using MSMQ, you must install MSMQ on a computer in your network and create at least one public queue.

Note

Whenever the word "queue" is used in this topic, it refers to a queue created and maintained using MSMQ.

To receive documents using MSMQ, you must install MSMQ and create at least one queue on a computer that has Application Object Server (AOS) installed, and that has been configured to run the AIF batch jobs. For more information about these batch jobs, see Start and stop the asynchronous Application Integration Framework (AIF) services.

To configure the MSMQ adapter (AifMSMQAdapter) for use in a channel, see Configure an adapter and Configure a channel.

1. Install MSMQ on a Windows Server 2003 computer

To configure MSMQ to receive documents, you must install MSMQ on a computer with AOS installed. This computer must also be configured to run the AIF batch jobs that execute the AIF services.

1. Click Start > Settings > Control Panel > Add or Remove Programs > Add/Remove Windows Components.

2. Select Application Server.

3. Click Details.

4. Select Message Queuing.

5. Click Details.

6. Select Active Directory Integration and Common.

7. Click OK.

8. Click OK.

9. Click Next to install.

2. Create a queue

A queue for inbound messages can be either private or public; a queue for outbound messages must be public.

1. Click Start > Settings > Control Panel > Administrative Tools > Computer Management.

2. Under Services and Applications, expand the Message Queuing folder.

3. To create a new public queue, right-click the Public Queues folder and click New > Public Queue.

4. To create a new private queue, right-click the Private Queues folder and click New > Private Queue.

Any queue used for receiving messages must be located on the same computer as the AOS that is configured to run the batch jobs that operate on the AIF queues. For

more information, see Start and stop the asynchronous Application Integration Framework (AIF) services.

5. Enter a name for the queue.

6. Click the Transactional check box.

7. Click OK.

3. Configure a queue for sending or receiving documents

AIF requires all inbound messages to be authenticated. When using MSMQ, authenticated messages are passed to AIF through authenticated or unauthenticated queues. AIF does not provide authentication for outbound messages, so you must configure outbound queues to be unauthenticated.

1. Click Start > Settings > Control Panel > Administrative Tools > Computer Management.

2. Under Services and Applications, expand the Message Queuing folder.

3. Right-click the queue you created and click Properties.

4. If you are configuring an inbound queue, on the General tab, select Authenticated. If you are configuring an outbound queue, clear Authenticated.

Inbound messages must be authenticated. That is, inbound messages that are not authenticated fail to reach their destination (the local endpoint).

5. On the Security tab, set ACLs appropriately for all queues.

When configuring the ACLs for newly created MSMQ queues, ensure that the current, logged-in user retains Full Control over each queue. If the current, logged-in user is denied certain privileges, they may become locked out of the queue and unable to make changes.

By default, Everyone and Anonymous Logon users can send messages to any newly created queue. Only the creator of the queue and an Administrator can receive messages from the queues.

For inbound queues, select Allow on Receive Message and Peek Message for the AOS account (the domain account or Network Service account associated with the AOS instance). Select Allow on Send Message, Get Properties, and Get Permissions for endpoint users only. For more information about configuring endpoint users and trusted intermediaries, see Configure an endpoint.

For outbound queues, set the ACLs to select Allow on Send Message, Get Properties, and Get Permissions for the Anonymous Logon user. Select Allow on Receive Message and Peek Message for endpoint users only.

If the inbound queue is not on the same machine as the AOS, then two additional entries need to be added to the queue's ACL. First, add the account for the AOS computer (for example, domain\computer-name$), and select Allow on Peek Message and Receive Message. Second, grant the Peek Message and Receive Messagepermissions for the Anonymous Logon.

6. On the Security tab, click Advanced.

7. On the Owner tab, set the Current owner of this item: to be the logged-in user who performs the document exchange.

8. Click OK to exit the menus.

9. Log off and then log back on to the computer.

AIF Messages [AX 2012]Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

This section of the documentation describes the tags used in Microsoft Dynamics AX services Application Integration Framework (AIF) messages. An AIF message uses XML to describe a self-contained unit of data that can consist of several parts. These parts include a <Header> tag section and a <Body> tag section. All XML used in AIF is validated against the appropriate schema. For more information about AIF messages and schemas, see Messages and transforms in AIF.

When you set up an inbound integration port and run an inbound service, AIF receives and processes an inbound message and generates an outbound message in response. When youset up an outbound integration port and run an outbound service to send data outside Microsoft Dynamics AX, AIF sends an outbound message. For more information about inbound and outbound integration ports, see Integration ports and Managing integration ports.

The tag names in the <Body> section vary between different types of inbound and outbound messages. The tags that are required in the <Body> section for Microsoft Dynamics AX document services depend on which service operation is specified in the <Action> tag in the <Header> section.

Message Header [AX 2012]Other Versions

This topic has not yet been rated - Rate this topic

Updated: June 18, 2012

Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

This topic describes the <Header> tag section of inbound and outbound messages in Application Integration Framework (AIF). For more information about AIF messages, see AIF Messages.

Note

This topic has been updated to include information about features that were added or changed for Microsoft Dynamics AX 2012 R2.

XSD Schema Validation

In the message XML, the <Header> tag is nested one level under the <Envelope> tag. The <Header> section in inbound and outbound messages must validate against the same XSD schema. The XSD is stored in the database in the AifSchemaStore table. The XSD schema for the <Header> section is duplicated in the file Message.xsd that is included with

Microsoft Dynamics AX under the installation directory. For more information, see Messages and transforms in AIF.

Table of Contained Tags

The following table lists all the tags that can appear in the <Header> tag section. All tags are optional unless they are described as required in the table. The tags must appear in the same sequence they are listed in the table.

Tag name Inbound description Outbound description

<MessageId> This value uniquely identifies each message. If you do not provide a MessageId value, AIF generates one when the message is received.

The value is a GUID that is not case sensitive. As an option, the value can be bounded by braces (the two characters {}).

The value is replicated in the <RequestMessageId> tag of the corresponding outbound message. You can use this value to locate the particular message on the Exceptions, Queue manager, and History forms. For more information, see Monitoring services and AIF.

By default, the inbound message is rejected if the system has seen this same <MessageId>value before for create, delete, and update service operations for the document services included with Microsoft Dynamics AX. For more information, see How to: Enable Checking for Duplicate Messages.

The system generates a unique GUID value for each outbound message.

<LogonAsUser> This is the name of the authorized Microsoft Dynamics AX user on whose authority the inbound request is being made.

The value must be a valid Microsoft Dynamics AX user or user group expressed as a string in the format “Domain\User.”

This value is used when trusted intermediaries are configured for an integration port using the AIF trusted intermediaries form. For more information, see Configure security for integration ports.

The inbound value is repeated in the outbound message.

<Company> This is a string value that identifies the company to use when you are retrieving data in a query from Microsoft Dynamics AX.

If no company is specified, the default company is used.

If an explicit value was given for the <Company>value is reused for thecorresponding outbound message.

<Action> This tag is required.

The value is a string that contains information that uniquely identifies the service operation to the system.

This tag is required. The value is identical to the inbound value.

<ConversationId> This is a string value that several inbound messages have in common to force AIF to process only one message in the set at a time. The messages in the conversation are processed sequentially even when the channel is configured for parallel processing.

The maximum length of the string is 256 characters.

If no value is specified, a setting on the port determines whether the messages are processed sequentially or in parallel. For more information, see Configure processing options.

For more information about how conversation IDs work with batched messages, seeProcessing batched messages in AIF. For more information about how conversation IDs are used in parallel processing scenarios, see Sequential and parallel processing in services and AIF.

The same value as was in the corresponding inbound message.

<RequestMessageId>

Does not apply to inbound messages. AIF puts theinbound message into this tag. This enables you to determine which outbound message corresponds to your inbound message.

<PartitionKey> This is a string value that specifies the partition for the data that is used in the service operation.

The default value for PartitionKey is the data partition that is set for the

If an explicit value was given for the<PartitionKey>that value is reused for the

calling user. For more information about data partitions, see Data partitioning architecture.

This option is available only if Microsoft Dynamics AX 2012 R2 is installed.

the corresponding outbound message.

This option is available only if Microsoft Dynamics AX 2012 R2 is installed.

Elements of the <Action> Tag

The <Action> tag consists of three elements: the namespace, the external name of the service, and the service operation, or method on the service class. The following example is for the Customer Service (that is, the CustCustomerService class), shown with line breaks to improve readability:

<Action>http://schemas.microsoft.com/dynamics/2008/01/

services/CustomerService/

read</Action>

The following table shows the elements of the <Action> tag for the example.

Element Portion of the <Action> value Location in AOT

Namespace http://schemas.microsoft.com/

dynamics/2008/01/services/

Under the Services node, on the CustCustomerService

Service Name CustomerService Under the Services node, on the CustCustomerService

Service Operation

read Under the Services node, under the CustCustomerServiceon the Read node, the Name property.

Another property is the name of the Method on the service class. Usually

the Name and Method properties have the same value.

The items specified in the <Action> tag determine the XSD schemas that the <Body> tag contents must comply with.

<Action> Tag: Service Class

The services that are exposed by Microsoft Dynamics AX are listed on the Select service operations form. To view the available service operations, click Service operations on the Service contract customizations FastTab for any inactive inbound or outbound integration port. For more information, see Customize service contracts. Every service that islisted on that form is also listed in the AOT in the Services node.

<Action> Tag: Service Operation for Document Services

The following table lists the service operations that are available for document services.

Service operation name

Description

create Inserts new records into the database.

delete Deletes records from the database.

find Reads complete data from records that match the specified fields and values.

findKeys Reads the key values from records that match the specified fields and values.

read Reads complete data from records that match the specified key values. Read is a subset of the

less verbose syntax.

update Modifies data in existing records, which are selected by the specified key values.

getKeys Returns only the key values for the entities returned in a query.

getChangedKeys Returns only the key values for the entities that have changed after the specified timestamp.

Each type of <Action> message can affect zero, one, or many records.

For more information about service operations for document services, see Document Class Service Operations.

Message Body [AX 2012]Other Versions

This topic has not yet been rated - Rate this topic

Updated: June 18, 2012

Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

This topic describes the <Body> tag section of inbound and outbound messages in Application Integration Framework (AIF). The <Body> tag must follow the

closing </Header>tag. For more information about messages and their format in Microsoft Dynamics AX, see Messages and transforms in AIF.

For examples of inbound and outbound messages, see Example of Inbound XML Message and Example of Outbound XML Message.

The <MessageParts> Tag

The first tag nested under <Body> must be the <MessageParts> tag. There is no requirement to specify the xmlns attribute on the <MessageParts> tag because the correct value is already specified on the outer <Envelope> tag.

Tags Required for <Action> Values

The values in the <Action> tag determine the XSD schema validations that are applied to the contents of the <Body> tag. The <Action> tag is nested under the <Header> tag.

For more information about actions, see Document Class Service Operations.

Tags in the <Body> of Inbound Messages

The outermost tag in each table cell occurs immediately after the <MessageParts> tag, and is nested directly under the <MessageParts> tag. The following example shows the nesting relationship between the <MessageParts> tag and the tags in the body of an inbound Find message .

Xml

<Body> <MessageParts> <QueryCriteria> <CriteriaElement> ... </CriteriaElement> </QueryCriteria> </MessageParts></Body>

For inbound messages, the following table shows the XML tags that must be in the <Body> tag section for each action.

Service operation in<Action> Tags in the inbound <Body>

Create <serviceExternalName>

o <entityName>

Examples could be as follows:

<Customer>

o <CustTable>

The following example shows the XML for a Create action for the LedgerJournal

<Body> <MessageParts xmlns = "http://schemas.microsoft.com/dynamics/2008/01/ documents/Message"> <LedgerJournal xmlns = "http://schemas.microsoft.com/dynamics/2008/01/ documents/LedgerJournal"> <LedgerJournalTable class="entity"> <CurrencyCode>USD</CurrencyCode> <JournalName>Day1</JournalName> <JournalTotalCredit>50</JournalTotalCredit> <JournalTotalDebit>50</JournalTotalDebit> <JournalType>Daily</JournalType> <Name>Daily Journal 1</Name> <VoucherSeries>Ledger_3</VoucherSeries> <LedgerJournalTrans class="entity"> <AccountNum>11010</AccountNum> <AccountType>Ledger</AccountType> <AmountCurDebit>50</AmountCurDebit> <CurrencyCode>USD</CurrencyCode> <DocumentDate>2007-05-28</DocumentDate> <Invoice>00003</Invoice> <OffsetAccount>12020</OffsetAccount> <OffsetAccountType>Ledger</OffsetAccountType> <TransDate>2007-05-28</TransDate> <Txt>AxLedgerJournal inbound test trans 1</Txt> </LedgerJournalTrans> </LedgerJournalTable> </LedgerJournal> </MessageParts> </Body>

Delete <EntityKeyList>

o <EntityKey>

Find <QueryCriteria>

o <CriteriaElement>

FindKeys, GetKeys, GetChangedKeys

<QueryCriteria>

o <CriteriaElement>

Read Same as Delete.

Update The following tags must come first:

<EntityKeyList>

o <EntityKey>

The following tags must come next:

<serviceExternalName>

o <entityName>

The tags <EntityKeyList> and <serviceExternalName> are at the same level of nesting underBoth tags are nested one level deeper than <MessageParts>, which is their parent tag.

The <EntityKey> tag sequence must align with the <entityName> tag sequence.

Tags in the <Body> of Outbound Messages

For outbound messages, the following table shows the XML tags that occur in the <Body> tag section for each action.

Service operation in <Action> Tags in the outbound <Body>

Create <EntityKeyList>

o <EntityKey>

Delete The <MessageParts> tag section is empty.

Find <serviceExternalName>

o <entityName>

FindKeys, GetKeys, GetChangedKeys <EntityKeyList>

o <EntityKey>

Read Same as Find.

Update Same as Delete.

Details About Each Tag in the <Body> Section

The following sections discuss the tags in more detail.

<EntityKeyList> Tag

The <EntityKeyList> tag section contains one or more <EntityKey> tags. The following is thecorrect syntax for the <EntityKeyList> tag (with a line break added to improve this display).

<EntityKeyList xmlns = "http://schemas/microsoft.com/

dynamics/2008/01/documents/Message">

<EntityKey> Tag

Each record in a table is uniquely identified by its value in the key field. In some tables the key is a set of two or more fields. The <EntityKey> tag section specifies the name and value for each key field. Each <EntityKey> section identifies at most one record.

The service class specified in the <Action> tag determines the table (or data source) that contains the records targeted by the <EntityKey>.

<EntityKey> Example

The following XML code is an example of the <EntityKey> tag section. It identifies the recordthat has a value of 4507 in its AccountNum field. Not shown is XML code elsewhere in the message that relates this <EntityKey> to the CustTable table.

Xml

<EntityKey xmlns = "http://schemas.microsoft.com/ dynamics/2006/02/documents/EntityKey"> <KeyData> <KeyField> <Field>AccountNum</Field> <Value>4507</Value> </KeyField> </KeyData></EntityKey>

<serviceExternalName> Tag

This tag is named for the document service that is specified in the <Action> tag.

<entityName> Tag

This tag is the name of the table (or data source) that the inbound message operates against. Nested under this tag are tags for each field in the table (or a subset of those field tags).

Also, nested under this tag could be another <entityName> tag for a child table. This can occur for create and update <Action> operations. For example, under the<SalesOrderTable> tag there can be a <SalesLine> tag.

<QueryCriteria> Tag

The <QueryCriteria> tag section contains one or more <CriteriaElement> tags. The <QueryCriteria> tag offers more flexibility than does the <EntityKeyList> tag. Unlike the <EntityKeyList> tag, the <QueryCriteria> tag never occurs in an outbound message.

For more information, see Query Criteria Overview.

<CriteriaElement> Tag

For matching records, the <CriteriaElement> tag section can specify field-value pairs that are not limited to key fields. The <CriteriaElement> tag also offers several operators beyondthe equals operator.

XSD Validations

The XSD schemas that are used to validate all parts of each message are stored in the following directory where you installed Microsoft Dynamics AX:

Program files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\bin\Application\Share\Include

For more information about XSD schema, see the following topics:

Messages and transforms in AIF

Document Schema Rules

How to: Generate a Document Schema

Query Criteria Overview [AX2012]Other Versions

2 out of 2 rated this helpful - Rate this topic

Updated: January 20, 2012

Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

This topic describes the <QueryCriteria> tag in inbound messages for Application Integration Framework (AIF). The <QueryCriteria> tag occurs in the <Body> tag section of an inbound message. The <QueryCriteria> tag never occurs in outbound messages. For more information, see Message Body.

The purpose of the <QueryCriteria> tag is to provide a flexible way to control which records are returned from an inbound message. The <QueryCriteria> tag is valid only in messages that have Find or FindKeys specified in their <Action> tag. The <QueryCriteria> section is more flexible than the <EntityKeyList> section.

Example <QueryCriteria> Section

The following XML code illustrates an inbound message. The message has an <Action> tag (not shown) which contains the CustomerService service, and the FindKeysservice operation.The code shows a <QueryCriteria> section that contains two <CriteriaElement> tags.

The system uses Boolean OR logic to connect all the <CriteriaElement> tags. This means that the record information returned in the outbound message comes from records that satisfy any one of the following <CriteriaElement> conditions.

Xml

<QueryCriteria xmlns = "http://schemas.microsoft.com/ dynamics/2006/02/documents/QueryCriteria">

<CriteriaElement> <DataSourceName>CustTable</DataSourceName> <FieldName>Street</FieldName> <Operator>Range</Operator> <Value1>1</Value1> <Value2>5</Value2> </CriteriaElement>

<CriteriaElement> <DataSourceName>CustTable</DataSourceName> <FieldName>Name</FieldName> <Operator>Equal</Operator> <Value1>Northwind Traders</Value1> <Value2/> </CriteriaElement>

</QueryCriteria>

Tags in the <CriteriaElement> Section

The following table lists the tags that occur in the <CriteriaElement> section.

Note

All the tags are required except for <Value2>, which is required only when the Range operator is used.

Tag name Description

<DataSourceName> The name of the table that is targeted for the search. The table must be the one that is targeted by the service that is specified in the <Action>

<FieldName> The name of a field in the table.

<Operator> One of several recognized operators, such as GreaterOrEqual

<Value1> The string representation of any value that is appropriate for the type of field specified.

<Value2> The second operand, used only when the Range

The following sections provide more details about some of the tags in the previous table.

<DataSourceName> Value Aligned with Service

You can determine the correct XML tag name for any service that is specified in the <Action> tag. The determination process is described by the following steps, which use the service CustomerService as a specific example.

1. Open the Inbound ports form. Click System administration > Setup > Services and Application Integration Framework > Inbound ports.

2. Click New to create a new port.

3. On the Service contract customizations FastTab, click Service operations to open the Select service operations form and select the CustCustomerService.createoperation.

4. Click the left arrow button to move selected service operations to the Selected service operations list and close the form.

5.

6. Select Customize documents and then click Data policies to open the Documentdata policies form.

7. Click the View schema button.

8. In the Schema window that is displayed, the name attribute of the first element is the name that you must use for the first tag under <Body><MessageParts> in your inbound message. The name of the first element in our example is Customer, as is shown in the following schema code.

Xml

<xs:element name="Customer" type="tns:AxdCustomer" />

<Operator> Values

The following table shows all the operators that are recognized as valid <Operator> tag values.

<Operator> value Analogous X++ operator

Equal ==

NotEqual !=

Greater >

GreaterOrEqual >=

Less <

LessOrEqual <=

Range >= && <=

Note

The Range operator cannot be used to query hidden or locked ranges for a data source or field. For more information about thequery range, seeQuery Properties.

XSD Validations

The <QueryCriteria> section is validated against an XSD schema. You can retrieve XSDs for common schemas from the following directory where you installed Microsoft Dynamics AX:

Program files\Microsoft Dynamics AX\60\Server\MicrosoftDynamicsAX\bin\Application\Share\Include

Example: Fault in an Outbound Message [AX 2012]Other Versions

This topic has not yet been rated - Rate this topic

Updated: January 10, 2012

Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

When the Application Integration Framework (AIF) receives and processes an inbound message, it generates an outbound message in response. If any error has occurred in processing the message, the service can generate information about the error to include in the response. This topic describes the <Fault> tag that occurs in outbound messages that report an error in the corresponding inbound message.

Outbound <Fault> Example

The following XML code example shows a <Body> tag section that contains a <Fault> tag. The <Text> tag contains the textual information that you can use to diagnose the problem.

Xml

<Body> <MessageParts xmlns = "http://schemas.microsoft.com/ dynamics/2008/01/documents/Message"> <Fault xmlns = "http://schemas.microsoft.com/dynamics/ 2008/01/documents/Fault"> <Code>RequestFailed</Code> <Reason> <Text xml:lang = "EN-US" >Request Failed. See the Exception Log for details.</Text> </Reason> </Fault> </MessageParts></Body>

View the Exception Log

The <Text> tag in the previous example instructed the user to view the Exceptions log. The log can be viewed in the Exceptions form. Click System administration > Periodic> Services and Application Integration Framework > Exceptions. In the Exceptions form, you can view information aboutthe module and subsystem where the error occurred, and a description of the error. You can also view information about when the error was logged, the user who is associated with the error, and the form or business logic where the error occurred.

You can include the information in the exception log in the response on an inbound port by setting Include exceptions in fault in the Troubleshooting area on the Inbound ports form. Click System administration > Setup > Services and Application Integration Framework > Inbound ports. For more information, see Configure troubleshooting options for integration ports.

XSD Validations

The <Fault> tag section is validated against the Fault XSD. You can retrieve XSDs for common schemas from your Microsoft Dynamics AX installation. The path of the directory resembles the following:

\Program files\Microsoft Dynamics AX\60\Server\<MicrosoftDynamicsAX installation ID>\bin\Application\Share\Include