Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Friday, June 29, 2007

Setting up perimeter network for EP

Well,

I know I said I am going on vacation, and I am. I did however read at Arijit [DAXGuy Site] blog, and saw his latest post about a document that you can download from the Microsoft site for setting up a perimeter network for Enterprise Portal, External Role, in Dynamics AX 4.01.

I thought this is a good post, and that more people working with EP and Dynamics AX 4.01 should have a better understanding of. Setting up EP can be a pain, but once setup it works great. So thanks Arijit for the post, you can find it here: Setting up traditional perimeter network for EP.

Well this is my *last* post before I go on vacation. I hope everyone has a great weekend, and 4th of July. Be safe and God bless you all!

Check back week after next for new post, as we continue on!

Find a job at: www.DynamicsAXJobs.com

Labels: , , ,

Wednesday, June 27, 2007

Some Vacation

Well,

It's beach time. I will be going on vacation, and spending some time with my family. I hope everyone had a wonderful next two weeks, and I will be back online posting in full then. In the meantime, feel free to leave comments, etc. and check back as we continue to explore the Dynamics world we work in. ;-) [Lame Pun there.]

See you all when I come back!
-Brandon George

Find a job at: www.DynamicsAXJobs.com

Labels: , ,

Monday, June 25, 2007

.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

Labels: , , , , , , ,

Wednesday, June 20, 2007

.Net BC, C# - Working with AxaptaRecord Object

In moving forward with my post about working with the .Net BC and C# below is some sample code of working with an AxaptaRecord object. With this object you can call upon a DataBuffer or better known as a table variable and perform X++ SQL Statements to fill the given object with data to work with. This means that all logic, checking, validation, and methods are exposed via this object that may exist for the given DataBuffer, ie: AxaptaRecord object. Let's take a look at the code:


AxaptaRecord axRecord;
String FieldValue1;
String query;

objDAXCn = (Axapta)Session["objDAXCn"];

if (objDAXCn == null)
return "";

try
{
axRecord = objDAXCn.CreateAxaptaRecord("SomeTable");
query = "select FieldValue1 from %1 where %1.SomeKeyValue == '" + _PassedInVariable + "'";
axRecord.ExecuteStmt(query);

if (axRecord.Found)
FieldValue1 = (string)axRecord.get_Field("FieldValue1");
elseM
FieldValue1 = "";

return FieldValue1;
}
catch
{
// Do something here
}

Alright so with the above block of code what are we doing?
First we are gettting the Axapta object for our connection from a session variable. We then perform a check to see if the given object is null. If so we simply return a blank value. Here though one could re-establish the connection, report back an error, etc. The next peice to this is we call the Axapta Object.CreateAxaptaRecord() call and set our AxaptaRecord object equal to that. Notice this is done Before we call for the query to be used to fill the object with data. Next we set our Query variable equal to the select statement of choice.
Notice this is X++ SQL Statements, and notice that the %1 is used. This is because the name of the table is passed as the create of the object, and the %1 refers to said name, because the Query that is passed in is formatted internally with a strfmt() function. The next thing if we is check if a Record is found, and if so set our variable to that field value, otherwise blank it out. Very simple, but very powerful.
Here we could have created advanced DataSets that where filled, and perform for or while blocks of code used to loop through all the records found, etc. Anyway this code is very useful, and makes it possible to make use of the Business logic that may be contained at the Table object level from within the AOT. Again you can get really advanced with this, but this should give you an idea of how to work with the AxaptaRecord object.

Well please leave comments, and check back as I continue down this path in exploring with you different ways to interact with objects via the .Net BC from C#!


Find a job at: www.DynamicsAXJobs.com

Labels: , , , , , ,

Friday, June 15, 2007

Passed 70-431 SQL 2005 Exam!

Well I am been preparing all week, and today I took the 70-431 exam. Man what a hard exam, after 3 hours of the stuff I completed it, and then when I saw the congrats meessage I said "Thank you God!"

Truly I thank my Creator and Christ for giving the ability to pass it! So now I am a MCTS - SQL 2005

Now for a little break, and a fun weekend, and back to it! I will again pick up the post next week on the .Net BC! Check backk soon!

Find a job at: www.DynamicsAXJobs.com

Labels: , , ,

Thursday, June 14, 2007

A Dynamic Solution for a Dynamic Company: American Apparel chooses Microsoft Dynamics AX and Sunrise Technologies

Well, I have the latest exciting news release from Sunrise Technologins, Inc. [Sunrise Web site.

Just released yesterday, is the PR talking about the latest client added to the long list for Sunrise American Apparel. Below is some comments from the PR:

“We chose Dynamics AX over several other ERP systems for its flexibility, scalability, and wide breadth of functionality. We liked the roadmap presented to us by Microsoft as well as their official support of partners devoted to providing industry specific solutions,” stated America Apparel’s IT Director, Jeff Kolb.

And...

“The team at Sunrise Technologies showed deep industry knowledge and was always willing to back up their promises with detailed demonstrations, creating confidence and enthusiasm in our users,” Kolb commented. The familiar User Interface elements in the system, integration across the Microsoft platform, and SQL/.NET on the back end satisfied technical staff at American Apparel and fit their skill sets. Kolb sees a bright future with Sunrise and Dynamics AX, “We believe that AX will be a cost effective platform to further streamline our business and support future growth.”

Microsoft's comments on the matter where:

Bill Gerrish, Microsoft’s Strategic Engagement Manager for the project, added, “I had the opportunity to work with the Sunrise team throughout the entire ERP evaluation at American Apparel. They demonstrated the willingness to ‘do whatever it takes’ to earn this business. The Sunrise team, clearly proved their apparel expertise, introduced their Apparel solution, as well as an experienced and credible team to lead the implementation.”

To read the full PR please click on the link above! Way to go Sunrise!

Well check back later on as I continue the post into ASP.Net / C# working with the .Net BC and Dynamics AX Objects!


Find a job at: www.DynamicsAXJobs.com

Labels: , , , , , ,

Wednesday, June 13, 2007

Vista, IIS 7 and .Net BC

Alright so in light of last weeks post about the .Net BC I had a fellow Architect email me about a issue he is facing. Basically he has the follwing:

- Vista
- IIS 7
- .Net BC

Next he has configured a AD account to have rights as a business connector proxy. Now he has taken the AD account and set it up as the identity of the Application pool for his application. When he uses a LogonAs() method call from C# ASP.Net application it crashed everytime. Now I am posting this here, because I have not yet tested the .Net BC on IIS 7. I am wondering if there is some kind of issue with isolation in the worker process for the Application Pool? Or even possibly what verison of .Net the person is trying.

Either way I wanted to post and see if anyone has had the chance to use the .Net BC from IIS 7 and Vista? What has been your experinces? What kind of code and setup have you used?

If you have anything to add here, please do so via the Comments below! Also when I have time I will come back to this, and also re-post about my experince with this in testing this out. Well check back as tomorrow I will continue my post and talk more about example C# ASP.Net code calling and working with Dynamics AX objects.

:-)

Find a job at: www.DynamicsAXJobs.com

Labels: , , , , ,

Sunday, June 10, 2007

MSDN Dynamics Developer Page

Alright,

So I was doing some weekend reading, and went to Arijit's blog. He had posted this week about the MSDN Dynamics Developers landing page. This page covers all the Dynamics Brand. So I followed the link to check it out, and man they really got some great stuff out there. Nice looking page on top of that! Anyway for sure it is a resource that Dynamics Professionals and Customers alike should have. So here is the link: MSDN Dynamics Developer Page

Thanks Arijit for postings this! [You can visit him at: DAXGuy [Arijit]]

Well check back next week as we continue to go deeper into the .Net BC and customer ASP.Net Application!

Find a job at: www.DynamicsAXJobs.com

Labels: , , , , , ,

Friday, June 08, 2007

.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

Labels: , , , , , , ,

Thursday, June 07, 2007

.Net BC Custom App, One Step Back! [Connection]

At the request of one of my readers, let me take a step back and talk about the Business Connector and how to make a successful connection to a Dynamics AX instance through it.

So to set this up let's talk about some important things here. One the Business Connector Proxy. This is the account that is used to start a BC session, in which all "connections" for the shared application pool for IIS go through.

In the EP example you supply this in the Business Connector Proxy form, and then the Applicaiton Pool that is running the SharePoint Portal EP site, Idenity must be the supplied Business Connector Proxy account that was setup in the Dynamics AX form. In our example, we have a standard Application pool. [Because we assume a single site for the IIS, for simple implementation of our custom site.] Since this is the case, then the First person to logon to the custom site can be used as the Business Connector Proxy account, and then all other user connection coming in with use the BC Proxy account, as long as that user account is active and does not time out. If that account does, then the next person to logon will assume the BC proxy account. You can see this in the Online users form. Admin > Online Users.

To achieve this, 2 things must happen. (1) The users using this application must have rights to logon as Business Proxy Account. (2) In your connection code you must make use of a Network credenitals object, and use the LogonAs() method. Let take a look at some sample connection code below:

Example Connection Code:

// Declartions
public Axapta objDAXCn;
System.Net.NetworkCredential nc;

// Make use of Declartions
nc = new System.Net.NetworkCredential(UserId, passwd, NetworkDomain);
objDAXCn = new Axapta();
objDAXCn.LogonAs(userId, NetworkDomain, nc, StartCompany, "", FQAOSInstance, "");
objDAXCn.Refresh();

Session["objDAXCn"] = objDAXCn;

Now lets take and break this down. First we have the declartions. We declar for an Axapta object, and then a NetworkCredential object. These are used as part of forming our connection for the given ASP.net session. Next we take and declare new for the given nc variable and then set it equal to passed in variables. Could be from a login scsreen. The nc is set then, and we move to setting the Connection object [Axapta] to a new instance. Next we perform the .LogonAs() [And not .Logon()] with passing the:

1. userId - From the passed in login screen
2. NetworkDomain - possible Global.asax global variable
3. nc - The given network credentials that will be used for the .Net BC Proxy account. [Unless a session already exists for the instance, then the existing BC Account is made use of]
4. StartCompany - What Dynamics AX company to start in
5. ""
6. FQAOSInstance - The Full name of the Dynamics AX instance. Example: "instanceName@ServerName:PortNumber"
7. ""

After this we perform a refresh and then set a session variable equal to the Open connection so it can be reused throughout the Site session for the given user. [performance helper].

So that is a good breakdown and coverage of making a connection via the .Net BC. YOu can get fancy with this for pooling, multiple Application Pools, single sessions, shared sessions, etc. etc. For now this will give you what you need, and your application should drive you to be as complex, Only as it needs to be. [Always use KISS method]

Well check back as we continue down this path!

Find a job at: www.DynamicsAXJobs.com

Labels: , , , , ,

Wednesday, June 06, 2007

.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

Labels: , , , , , , ,

Tuesday, June 05, 2007

Yellow Lock in Dynamics AX 4.01

Alright not to get off the subject about the .Net BC and custom code in .Net using it. But I did come across something, that I guess I have never had to come across before. Anyway we have custom code on a form where we had to make use of the TabChanged() method. This was needed, best thing for the mod, so there you go.

Well when users wanted to move some fields around on the lines level, they could not. When you right clicked, and then clicked on setup, you see Yellow Locks on all the objects in the tree view, under the tab control where the TabChanged() method was modified. So in research of this issue, turns out that this is "Working as Designed" as the *Offical* word from Mcirosoft Dynamics Support.

This means that you can't have your cake and eat it too, for this type of situation. Basically you modify the TabChanged() to TabChange() methods of a tab control, and you lock all fields in place as they exist in the AOT. So for everyone else who might run into this, just be aware this is the issue. The solution, do Not change those two methods, or just accept the users can't change the fields around and change them for the collective whole in the AOT.

Well check back as I continue my talks about the .Net BC and it's use for developing a custom ASP.Net application!

Let me add I realize that for some this has been a known issue since AX 3.0, but when I did my search on the web nothing came up about this. So I thought it worth while for future reference for Someone else to find, just in case someone needs it! :-)

Find a job at: www.DynamicsAXJobs.com

Labels: , , , , , , , , ,

.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

Labels: , , , , , , ,

Monday, June 04, 2007

ASP.Net and the Dynamics AX .net BC

I thought I would write this week about using the Dynamics AX .Net Business Connector from custom ASP.Net applications. This can be a wonderful in for making use of X++ business objects, and other DAX objects, but it can also be something tricky to work through, and throughly plan for.

The thing to keep in mind is that ASP.Net 2.0, and it's use of Domain specific context, or Application pool, is tied to a given .Net Business Connector Proxy account. This account can be any AD network account that has rights to logon as BC proxy. The first time the proxy is launched, it's rights as a user will be used, and stay present into the application pool / domain context is reset.

This can be a tricky thing, because for example you might have an custom ASP.Net application where you want one site per company, per instance. [Similar to the Enterprise Portal for Dynamics AX 4.01]. In doing this you must keep in mind that each site should have it's own port for setup, but also it's own Application Pool. Doing this will allow you to run multiple sites for the different possible companies, and instances that you might have for Dynamics AX and your site(s). Let me tell you, I know first hand, if you don't plan for this and try to run off of the same application pool, you will have the wrong data going into the wrong company and not know about it until you have some data clean up to do. :-)

Basically though if you think about an Application Pool in IIS / ASP.Net world as the Domain Context for which a given instance of a ASP.net application lives and works, then thinking in these terms will help you plan your custom ASP.Net application betters, and allow for multiple instances on the same IIS box.

Well check back as I will cotinue this discussion and move into some examples for working with Dynamics AX objects from ASP.Net in C#!

Find a job at: www.DynamicsAXJobs.com


Copyright 2005-2011, J. Brandon George - All rights Reserved