.Net BC Custom App, Advanced Connection Talk

Alright now that we have looked into what can be done to create a connection, lets talk about what kind of different setups can be done with this. The previous way I showed you, is one where the first for a given site to login is the granted .Net BC proxy account, in which the rest of the users login through. So if:

Sam logins, then in the Online users form you will see:

Sam, Connection Type = Business Proxy Account
Sam, Connection Type = Web User

And then as each other person logs in, you will see:

Sam, Connection Type = Business Proxy Account
Sam, Connection Type = Web User
John, Connection Type = Web User
Susan, Connection Type = Web User
Joe, Connection Type = Web User

As the day progresses, and Same leaves, maybe Joe get's logged in as the Business Proxy Account. Then Sam's first connection would be gone, and Joe would have what Sam has above. This works great for internal applications, internal, intranet based applications, where all users are part of the AD domain, and therefore easily managed.

Now for more advanced topics, lets say you have a high end web application, and you want consumers to login as web users, based on the web user, user relation data you setup for them. So what you could do here is:

(1) Take and create a new Application Pool in IIS for your site.
(2) Create a AD account that has correct rights in DAX, including Business Proxy Account rights.
(3) Set the identity for the Application Pool to the new user
(4) Instead of supplying the NC / Network Cred. Object with the given user, supply it with the one for the given Application Pool

What this does is it allows a given "generic" account from AD to be the Business Proxy Account for your custom site. Then you would have:

Site1Account, Connection Type = Business Proxy Account
CustomerA, Connection Type = Web
CustomerB, Connection Type = Web

And furthermore, in doing this option, you could setup multiple sites, for multiple instance of Dynmaics AX. So two very different approachs on this matter, and this all depends on the needs of your site, and what you are trying to accomplish. Just keep in mind the Business Proxy account is what all Web users make use of for executiong rights, and coming into Dynamics AX. Seperate rights can exists for Web Users for the different sections of Dynamics AX.

Well Check back soon as I continue my talks on the .Net BC and Custom ASP.Net Application series!


Find a job at: www.DynamicsAXJobs.com

.Net BC Custom App, Part III - Container Object

Well now we have talked a bit about design let's look into some sample C# code that works with different objects from Dynamics AX. First I want to take an object that is used a lot most likely in code, and can be very useful. That is a Container Object.

Working with an Container object from C#:

AxaptaContainer axContainer;
axContainer = (AxaptaContainer)objDAXCn.Call(StaticClassMethod"someClass","someStaticMethod",Var1,Var2,var3);

for (int i = 1; i <= axContainer.Count; i++)
{
// Preform Some code here on the returned container....
someStr = axContainer.get_Item(1).ToString();
}


Here we see exactly how to work with a Conatiner object from C#, and use a for loop call to enumerate through the container to work with the container elements. What makes the above path calls possible, is the header of the C# code contains the following:

using Microsoft.Dynamics.BusinessConnectorNet;

So we see now that if we had a static method on a class that could be coded to maybe get some data, and put that into a container object, then the above code could enumerate through that container and within C# you could work with that conatiners elements. I will continue down this path of of working with .Net BC and objects from
Dynamics AX via C#. I hope that you are enjoying this and that it helps someone out!

Check back soon!

Find a job at: www.DynamicsAXJobs.com

.Net BC Custom App, Part II

Well now that we talked a little bit about theroy / design behind the custom ASP.Net Application, lets talk about more on the design. In my thoughts, you always want to be absrtact. Meaning the layers that seperate and operate should be as much independant as they can.

Some rules of thumb here for me:

(1) All business logic lives in X++. This is Very important. Doing this keeps the AOS as the central point for performing all Business Logic on Dynamics AX related data and objects.

(2) All use of .Net BC code should be contained within a Web Service or Web Services. This is a very important layer of abstraction. This moves your solution into the JBOWS / SOA arena, where it needs to be anyway. This allows for multiple interfaces, into the same access logic. Meaning, though we are developing and custom ASP.Net application front end, we could easily create a Mobile Windows, regular windows, Java, etc. etc. number of front end or middleware interfaces into this same Web Service(s).

Now there can be other obvious and not so obvious rules of thumb that would apply, depending on the nature and design of the application. Like user size for example. Maybe your custom app will be used by a lot of concurrent users? So possible considerations for pooling, Session variables, connection pooling, as well as designing your application to work well in a web farm. Where multiple servers make up a single virtual server. All of these things must be considered in the design of your appliocation. For now though can be after thoughts that you decide when prompted for such needs.

So here we have our base design: (a) All business logic lives in X++, (b) All access to the business logic will be contained with web services.

This means you needs at least 1 instance of Dynamics AX, 1 AOS, and 1 IIS box. Preferred these be different boxes of course, but in development / test can be the same.

Alright well check back tomorrow as we continue our dive into our custom ASP.Net application!

Find a job at: www.DynamicsAXJobs.com