.Net Adapter and why?
Alright something that I have discussed a good bit with some clients, as well as associates is the need for creating .Net Assemblies that act as wrappers or better Adapters for connecting Dynamics AX to third part services / software. So I thought I would take a little break from the .Net Custom C# examples and write about this for a post.
Alright so say you have either a COM application or a .Net Assembly that you want to make use of inside Dynamics AX 4.01? Why not since both COM and .Net can now be referenced and used. Well some of the first things that you will run into in this is that X++ can not handle complex data types and return outs from given called COM methods or .Net Assembly methods. What does this mean? Let take for example you have a COM object that you want to make use. Say for example the COM API tells you something as the following:
COMObject.SomeMethod(STR VAR1, STR VAR2, OUT INT STATUS);
VAR1 = Some Variable
VAR2 = Some other variable
STATUS = Out supplied variable, returned at end of Method call
Now looking at the above, right off the bat we notice an OUT variable as being part of the method header / call. In X++ such a variable qualifer or call does not exists. If this is the case, then that means the given COM object method can not be used, and there goes your nifty idea... Not really. Enter the powerful world of .Net Wrappers / Adapters!
In order to allow for Dynamics AX to make use of the above COM object method call, you need to create an adapter that consumes the "complex" data type / method calls and Adapts them into a suitable form that X++ calls can make use of. So in our example we would create a C# .Net Class, that would live in an assembly (.DLL file) and have it call the above with VAR1, and VAR2 passed in. Then we would have an Internal to the .NetClassObject.Method(string Var1, string Var2) method call that would take and call the above as stated. The OUT int varible inside the .Net method call would then set a property of the .Net class equal to the value that was sent out, or return the value as the returned value for the .Net Method call.
But what if we did it the first way, set a property of the .Net Class / Object? well if that is the case [possibly multiple OUT vars] then you would have to create getClassProp() methods that could be called from X++ because even custom properties of a .NetClassObject can not be used from with X++.
So now we have the why, and basics of how for a .Net adapter. The point is to take complex calls and data types, consume them with the .Net Adapter you create, and expose via simple data types and simple method calls that can be used from within X++. The wonderful thing about this approach is the only time your developed .Net adapter changes is when the version of your Third Party software does!
Well check back soon as I continue my talks about .Net Custom code and using the .Net Business Connector for Dynamics AX 4.0.
Find a job at: www.DynamicsAXJobs.com
Alright so say you have either a COM application or a .Net Assembly that you want to make use of inside Dynamics AX 4.01? Why not since both COM and .Net can now be referenced and used. Well some of the first things that you will run into in this is that X++ can not handle complex data types and return outs from given called COM methods or .Net Assembly methods. What does this mean? Let take for example you have a COM object that you want to make use. Say for example the COM API tells you something as the following:
COMObject.SomeMethod(STR VAR1, STR VAR2, OUT INT STATUS);
VAR1 = Some Variable
VAR2 = Some other variable
STATUS = Out supplied variable, returned at end of Method call
Now looking at the above, right off the bat we notice an OUT variable as being part of the method header / call. In X++ such a variable qualifer or call does not exists. If this is the case, then that means the given COM object method can not be used, and there goes your nifty idea... Not really. Enter the powerful world of .Net Wrappers / Adapters!
In order to allow for Dynamics AX to make use of the above COM object method call, you need to create an adapter that consumes the "complex" data type / method calls and Adapts them into a suitable form that X++ calls can make use of. So in our example we would create a C# .Net Class, that would live in an assembly (.DLL file) and have it call the above with VAR1, and VAR2 passed in. Then we would have an Internal to the .NetClassObject.Method(string Var1, string Var2) method call that would take and call the above as stated. The OUT int varible inside the .Net method call would then set a property of the .Net class equal to the value that was sent out, or return the value as the returned value for the .Net Method call.
But what if we did it the first way, set a property of the .Net Class / Object? well if that is the case [possibly multiple OUT vars] then you would have to create getClassProp() methods that could be called from X++ because even custom properties of a .NetClassObject can not be used from with X++.
So now we have the why, and basics of how for a .Net adapter. The point is to take complex calls and data types, consume them with the .Net Adapter you create, and expose via simple data types and simple method calls that can be used from within X++. The wonderful thing about this approach is the only time your developed .Net adapter changes is when the version of your Third Party software does!
Well check back soon as I continue my talks about .Net Custom code and using the .Net Business Connector for Dynamics AX 4.0.
Find a job at: www.DynamicsAXJobs.com
Labels: .Net, Adapters, CLR, Complex Calls, Dynamics AX, Integration, Third Party, Wrappers
0 Comments:
Post a Comment
<< Home