Using C# code to connect to Ax 3.0
To continue down the path of integration with Ax 3.0, today I wanted to take the time and post some C# code that can be used in order to connect to the AxaptaCOMConnector 1.2 and use it to execute code.
The tricky thing about the COM Connector is the logon, and also when to use Null values for object values that need to be set. If you look at the VB.Net examples, you want see this. Also as part of this, I show you how to make use of the CallEx or CreateEx methods which take a ParametersList Array of values. I much prefer this, in the place of the standard call and having to use Null. In the example below though I make use of both so you can see the difference:
First the Connection code:
Using AxaptaCOMConnector;
private AxaptaCOMConnector.Axapta Ax()
{
// This method will return an Open AxaptaCOMConnector Object and allow for execution of needed
// Code.
Axapta _ax;
_ax = new Axapta();
try
{
_ax.Logon("jbg", "", "", "");
}
catch(System.Exception err)
{
System.Diagnostics.Debug.Print(err.Source);
System.Diagnostics.Debug.Print(err.StackTrace);
System.Diagnostics.Debug.Print(err.Message);
}
return _ax;
}
Now to keep things simple, the above code is ran on a box that contains the COM Connector and the Ax instance. With that in mind, the above code will return a new Axapta COM instance to be used to execute code.
Next let's use the connection we now have to execute code:
public Boolean InvokeItemIF(string VendorId,
string TableName) {
AxaptaCOMConnector.IAxaptaObject srInvokeItemIF;
AxaptaCOMConnector.AxaptaParameterList srInvokeItemParams;
Boolean result;
if (VendorId != "" && TableName != "")
{
try
{
srInvokeItemParams = new AxaptaParameterList();
srInvokeItemParams.Size = 2;
srInvokeItemParams.set_Element(1,(Object)VendorId);
srInvokeItemParams.set_Element(2,(Object)TableName);
srInvokeItemIF = AXCN.CreateObjectEx("srInvokeItem", srInvokeItemParams);
result = (Boolean)srInvokeItemIF.Call("ProcessItems2",null,null,null,null,null,null);
}
catch(System.Exception err)
{
result = false;
}
}
else
{ result = false; }
this.KillAXCN();
return result;
}
The above code here makes use of an IAxapaObject interface, and a AxaptaParameterList. With these along with our COM Connection we are able to take the passed in values of VendorId and TableName to then create a new Object which represents an Ax X++ class, that is then passed these values into the New() or constructor. From there we tell the Object to execute the ProcessItems2 method.
Here we use a Call and a CreateObjectEx. Both ways work, but I prefer to Ex because you are not limited on the amount of Params that you can pass. Once the call is completed to ProcessItems2, it returns a boolean value which we then return for this method.
Also part of this is the killAXCN() method call. This method is next:
private void KillAXCN()
{
// Close the Open AXCN connection
AXCN.Logoff();
AXCN = null;
}
Basically this method will take and destroy the COM Connection. Pretty striaght forward.
The issues that you run into when using the COM Connector is getting it to work in a production enviornment with multiple AOS(es). I always recommend having the COM Connector installed and registered on a Batch or Application server, which then has it's own configuration of AX to use, and also can host the Web Service that you use to expose access to the Ax COM Connection and code you need to execute.
Well Check back for more as I will dive deeper and deeper into this, as well as make the switch to 4.0 and talk about the differences!
Find a job at: www.DynamicsAXJobs.com
The tricky thing about the COM Connector is the logon, and also when to use Null values for object values that need to be set. If you look at the VB.Net examples, you want see this. Also as part of this, I show you how to make use of the CallEx or CreateEx methods which take a ParametersList Array of values. I much prefer this, in the place of the standard call and having to use Null. In the example below though I make use of both so you can see the difference:
First the Connection code:
Using AxaptaCOMConnector;
private AxaptaCOMConnector.Axapta Ax()
{
// This method will return an Open AxaptaCOMConnector Object and allow for execution of needed
// Code.
Axapta _ax;
_ax = new Axapta();
try
{
_ax.Logon("jbg", "", "", "");
}
catch(System.Exception err)
{
System.Diagnostics.Debug.Print(err.Source);
System.Diagnostics.Debug.Print(err.StackTrace);
System.Diagnostics.Debug.Print(err.Message);
}
return _ax;
}
Now to keep things simple, the above code is ran on a box that contains the COM Connector and the Ax instance. With that in mind, the above code will return a new Axapta COM instance to be used to execute code.
Next let's use the connection we now have to execute code:
public Boolean InvokeItemIF(string VendorId,
string TableName) {
AxaptaCOMConnector.IAxaptaObject srInvokeItemIF;
AxaptaCOMConnector.AxaptaParameterList srInvokeItemParams;
Boolean result;
if (VendorId != "" && TableName != "")
{
try
{
srInvokeItemParams = new AxaptaParameterList();
srInvokeItemParams.Size = 2;
srInvokeItemParams.set_Element(1,(Object)VendorId);
srInvokeItemParams.set_Element(2,(Object)TableName);
srInvokeItemIF = AXCN.CreateObjectEx("srInvokeItem", srInvokeItemParams);
result = (Boolean)srInvokeItemIF.Call("ProcessItems2",null,null,null,null,null,null);
}
catch(System.Exception err)
{
result = false;
}
}
else
{ result = false; }
this.KillAXCN();
return result;
}
The above code here makes use of an IAxapaObject interface, and a AxaptaParameterList. With these along with our COM Connection we are able to take the passed in values of VendorId and TableName to then create a new Object which represents an Ax X++ class, that is then passed these values into the New() or constructor. From there we tell the Object to execute the ProcessItems2 method.
Here we use a Call and a CreateObjectEx. Both ways work, but I prefer to Ex because you are not limited on the amount of Params that you can pass. Once the call is completed to ProcessItems2, it returns a boolean value which we then return for this method.
Also part of this is the killAXCN() method call. This method is next:
private void KillAXCN()
{
// Close the Open AXCN connection
AXCN.Logoff();
AXCN = null;
}
Basically this method will take and destroy the COM Connection. Pretty striaght forward.
The issues that you run into when using the COM Connector is getting it to work in a production enviornment with multiple AOS(es). I always recommend having the COM Connector installed and registered on a Batch or Application server, which then has it's own configuration of AX to use, and also can host the Web Service that you use to expose access to the Ax COM Connection and code you need to execute.
Well Check back for more as I will dive deeper and deeper into this, as well as make the switch to 4.0 and talk about the differences!
Find a job at: www.DynamicsAXJobs.com
0 Comments:
Post a Comment
<< Home