.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
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
Labels: .Net, ASP.Net, Business Connector, Custom, Dynamics AX, JBOWS, SOA, Web Services
posted by brandon | 8:01 AM
3 Comments:
Good Day
I am developing a set of web services to be the interface to the Dynamics AX functionality.
I plan on using the .Net BC.
I have one big issue with this.
From my tests it take 6-10 secs for the .Net BC to make a connection to Dynamics AX.
I am using WCF in perssession mode, with multiple calls per session, but I find that 6-10 secs is way to long to establish the initial connection. As they go out of scope when the session is finished, so I have to close them.
Is there a way I can pool/cache connections so I can re-use established connections from a pool for new web service sessions?
Regards
GregJF
Greg,
What your asking about is a BC pool. You can do this, via .Net, by creating yourself basically a BC Factory. Make this load up, with the number of BC's that already have logged in. Change the user each time is used, but the inital 3-6 seconds is no longer there... only when the entire application loads, which would be the Application Pool. So restart at night and first time the web site is hit the inital 3-6 seconds for each BC is hit and then throughout the day your sessions are fast.
I have actually created this before for a client and it works great.
Hope this helps.
There is a free tool I've made available at www.xppdotnet.com which may be of interest to developers working with the Business Connector. Happy to hear any comments/queries.
Post a Comment
<< Home