LedgerJournalTable you can use code below for posting into transactions
LedgerJournalTable you can use code below for posting into transactions
The Microsoft Dynamics AX runtime manages the storage of value type data on the call stack and reference type objects on the memory heap.
The call stack is the memory structure that holds data about the active methods called during program execution. The memory heap is the memory area that allocates storage for objects that are destroyed automatically by the Microsoft Dynamics AX run-time.
Value types include the built-in
primitive types, extended data types, enumeration types, and built-in collection types.
By default, variables declared as value types are assigned their zero value by the Microsoft Dynamics AX runtime. These variables can’t be set to null. Variable values are copied when variables are used to invoke methods and when they are used in assignment statements. Therefore, two value type variables can’t reference the same value.
Reference types include
the record types, class types, and interface types.
Reference variables declared as record types reference objects that the Microsoft Dynamics AX runtime instantiates automatically. Class type objects are programmatically instantiated using the new operator. Copies of object references are passed as reference parameters in method calls and are assigned to reference variables, so two variables can reference the same object.
Thank you for reading!
Document services use documents to represent business objects such as purchase and sales orders, customers, vendors, and so on.
A document service is composed of the following components:
AxBCclass is a wrapper for a table and contains business logic that is needed for Create, Read, Update, Delete (CRUD) operations.
AxdCustomerclass could contain logic to handle party information of a customer.
AifDocumentServiceclass. This class implements the service operations that are published through the service contract.
When creating document services, developers need to make sure that the business object is mapped correctly to the document query. The document services framework will handle all other things such as the serialization and deserialization of XML, date effectiveness, and so on.
Document services can be deployed using the integration ports and all available adapters can be used.
Custom services were already available in Microsoft Dynamics AX 2009, but support for Extended Data Types(EDTs) was limited, which resulted in developers having to provide custom serialization and deserialization logic.
Microsoft Dynamics AX 2012 introduces the concept of attributes. Attributes provide a way to specify metadata about classes and methods. Two of these attributes are used when creating data contracts: the
The ‘DataContractAttribute’ attribute is used to define that a class is a data contract. The’DataMemberAttribute’ attribute is added to methods of data contracts that represent data members that have to be exposed. This way of defining data contracts is very similar to other programming languages such as C#.
Support for more complex data types such as collections and tables has been added so that these types can be serialized and deserialized without developers having to provide the logic themselves.
In a typical custom service you will find the following components:
Custom services can be deployed using the integration ports and any available adapter can be used.
These services are new since the release of Microsoft Dynamics AX 2012. The main difference between these services and the previous two types is that they are not customizable and are not mapped to a query or X++ code. They are not customizable because they are written by Microsoft in managed code. One exception is the user session service, which is written in X++ code but is generally considered as a system service.
There are three system services available for use in Microsoft Dynamics AX 2012: the query service, the metadata service, and the user session service.
The query service provides the means to run queries of the following three types:
When queries are called by a service, the AOS authorization ensures that the caller has the correct permissions to retrieve the information. This means that unpermitted fields will be omitted from the query result. Furthermore, when joined data sources are not allowed to be used, the query call will result in an error that can be caught by the calling application.
The resulting rows will be returned as an ADO.NET DataSet object. This can be very useful when you make use of controls in your application that can be bound to a DataSet object.
The query service can be found at the following address:
This system service can be used to retrieve metadata information about the AOT. Consumers of this service can get information such as which tables, classes, forms, and menu items are available in the system. An example usage of this service could be retrieving information about the AOT and using it in a dashboard application running on the Microsoft .NET Framework.
The metadata service can be found at the following address:
The third system service is the user session service. With this service you can retrieve information about the caller’s user session. This information includes the user’s default company, language, preferred calendar, time zone, and currency.
The user session service can be found at the following address:
Now that it is clear what types of services Microsoft Dynamics AX 2012 has to offer, the question arises as to when each type of service should be used. There is no simple answer for this due to the fact that every type has its strengths and weaknesses. Let us take a look at two factors that may help you make the right decision.
Both document services and custom services can handle any business entity complexity. The document services framework parses the incoming XML and validates it against an XML Schema Definition(XSD) document. After validation, the framework calls the appropriate service action. Custom services on the other hand use the .NET XML Serializer and no validation of data is done. This means that any validations of the data in the data contract need to be written in code. Another advantage of document services over custom services is that the AxBC classes already contain a lot of the logic that is needed for CRUD operations.
Document services have service contracts that are tightly coupled with the AOT Query object. This means that when the query changes, the schema also changes. Data policies allow you to control which fields are exposed. When using custom services, this cannot be done by setup, but has to be done by attributing at design time.
Custom services have the flexibility towards the service contract that the document services are lacking. Here the developer is in full control about what is in the contract and what is not. The operations, input parameters, and return types are all the responsibility of the developer.
Another benefit in using custom services is the ability to use shared data contracts as parameters for your operations. Think of a company-wide software solution that involves the use of Microsoft Dynamics AX 2012 together with SharePoint and .NET applications that are all linked through BizTalk. You could opt to share data contracts to make sure that entities are the same for all of the components in the architecture.
In that scenario, you’re able to create a data contract in managed code and reference it in Microsoft Dynamics AX 2012. Then you can use that .NET data contract in your service operations as a parameter.
There will probably be more factors that you will take into consideration to choose between the service types. But we can come to the following conclusion about when to use what type of service:
They are also ideal when custom logic needs to be exposed that may have nothing to do with data structures within Microsoft Dynamics AX.
It can be used when writing .NET Framework applications that leverage the data from Microsoft Dynamics AX returned as an ADO.NET DataSet.