Beyond Dynamics AX with Business Intelligence

I hope everyone is having a blessed day, and you find yourself productive in our Dynamics filled world. May is once again here, and that means we tilt ever so closer towards our solar systems star - in the northern hemisphere that is. That also means planning for summer time vacation, baseball / softball, as well as an assortment of water related activities. The march towards summer begins, and that means the world around us continues to come alive.

With spring in full force, I thought it was time to talk about the needed topic of beyond Dynamics AX with Business Intelligence. Lets face it, more and more projects are being sold & implemented well, that has Microsoft Dynamics AX only acting as an operational ERP element. It's one spoke in the total solution for larger companies. When you have this reality, Dynamics AX is no longer the single data mart from which analytic's & insights are derived from.



As we see from the above image, when Dynamics AX is the data mart in which such BI artifacts solely are crafted around, then you have a very compelling story in which a companies total reporting needs can be told by. This is Sunrise's standard offering for business intelligence needs. That is: Office+SharePoint+SQL Server.

Are focus is expanded however, when the needs of the customer expand. To help facilitate the understanding of when and where this might be the case, let's start by listing a high level set of topics, that in turn will be used to guide into greater business insights for customers. Further, how each of these topics would drive to a more complete or total BI story that is crafted for a customer. All the while, keeping in mind that the tool is the last thing you focus on for a real BI project.

• Dynamics AX is a spoke, not the hub - Here we have a total solution scenario, where Dynamics AX is an operational ERP element in a customers total solution. This means 2:n possible line-of-business applications that complete an end-to-end solution for a customer. When this is the case, items like real data warehouses, ETL, Master Data Management across the systems, and more must come into the picture. This further means that what tools are best for achieving the ultimate end goal might need to be extended beyond the Office+SharePoint+SQL Server.
• Security & Exposure beyond the Dynamics AX walls - Here we have a need for an organization that has reporting requirements. These reporting requirements however dictate that there are business insights needed for employees that will not have, nor should not have access to Dynamics AX at all. When this is true, again, then we have directive for something that extends beyond the walled garden of Dynamics AX.
• Mobile BI across a multitude of platforms - There is a very compelling story that can be told with the BI stack of Office+SharePoint+SQL Server. Mobile is very much apart of this, specifically with the release of Office 2013 and SharePoint 2013. However when you want a mobile BI platform, that needs to reach beyond the Microsoft world, in a more native way, then extending beyond the BI stack that comes with Dynamics AX is needed.
• Abstraction - This last point is more focused around that true executive information system, or dashboard. With the continued improvements being made for Dynamics AX, and those improvements driving more technology and model churn, the need for abstracting away the C & B level executives from such churn is a valid one. Having something that extends beyond the Dynamics AX BI stack, can help abstract out the executive's and their analytical needs. Reality is, these might change some, but not at the rate in which technology, and further Dynamics AX is changing.

Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.

The above, by far is not a final list but something that hopefully has you thinking in terms of a more complete BI solution. There is hardly ever any truth in we bought (insert product name) now we have BI! Real business intelligence for customers is always about the data first, then reporting need second, and finally the product or products that help delivery on said need last. Take into consideration any of the above points, and you have a more larger requirement - where selecting specific tools first could halt the needed progression that is demanded by the organization.

Over the next several weeks, I will continue to expand upon each of the above topics, and others in how I feel these are best addressed. This includes both the stack that comes with Dynamics AX, and beyond that for a total solution offering.



That's all for this post, I hope you have enjoyed it and your excited to hear more. One final note, I would like to say that I'm honored to have been listed once again this year in the DynamicsWorld Top 100 list. Top 25 again this year! Honestly the amount of work that some of the people put into the ecosystem, that I can be included with amazes me. This community as a whole has grown leaps and bounds over the past 3 years. I can't say enough of how honored I am to be included as part of it. Til Next Time!


Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.


Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

AX 2012 R2 - Till Partition Do We Cubes Part

Well I hope everyone finds themselves doing well this fine Tuesday. There for sure is a lot of great things going on within the Microsoft Dynamics ecosystem. Spring is finally here for most of us, and everyone is well into this years projects. With this, I wanted to focus a bit on a new concept that came as part of Microsoft Dynamics AX 2012 R2. This concept is around partitioning within AX 2012 R2 and how that relates to the cubes that are built.



Before we get to far into this topic of 'Till Partition Do We Cubes Part', it's very important to understand the concept of the new partitioning that has taking place. To help with this, we can look at the following resources.:

• Data partitioning architecture [AX 2012]
• Partitions, Companies, and Data Isolation in Microsoft Dynamics AX [AX 2012]

Having the above resources, one can start to get an idea - at least technically - the what & how behind the concept of data partitioning in Dynamics AX 2012 R2. Now that we have at least a baseline level of knowledge in which to work from, lets move to the divorce seen in our tragedy.



Now sometimes in my writings I set a bit of flare to it, and this is no different. This tale is less of a tragedy really, but a concept that should be understood in how Microsoft see's Analysis Services working within the context of data isolation. You see, a lot of times it does not makes sense to have everything, including the kitchen sink, in a single cube. There are a lot of reason's, that separate, specifically design cubes would exist for a companies BI story. This happens to help address one of those, especially as you get into larger companies that need isolated data & security elements.

Here is where the value of such a separate plays into the crafting of said BI story for a company. Hence why we see in the examples that Microsoft provides for us. Keep in mind, that the cubes that come with Microsoft Dynamics AX are very generalized, and meant to act as a starting point for OLAP data. They are never meant to address a companies full, specific needs around analytic's.

So, in following with the image we see above partition key plays a role in the number of cube databases that an instance of Dynamics AX 2012 R2 is meant to have. The same cube structure however is found in both databases in the provided example. This implies that you can have similar analytic's that are rendered, but with security & data isolation needs addressed. Finally, if you so desired, you can easily create a cube structure that crossed partitions, or reporting elements that cross partitions. See the below, from so titled 'Partitions, Companies, and Data Isolation in Microsoft Dynamics AX [AX 2012.]'

"-- T-SQL to run in the Dynamics AX database directly in SQL Server: SELECT da1.Partition, pt2.PartitionKey, pt2.Name, da1.ID as [Company-ID] FROM DataArea as da1, Partitions as pt2 WHERE da1.Partition = pt2.RecId ORDER BY pt2.PartitionKey, da1.ID;"

Now do keep in mind what the following is prefaced with, in that: 'If you have sufficient authorization' This means to cross partitions and legal entities. Hence, this is not a technical issue, as much of a functional modeling, data & security isolation need. As you scale up and out with Dynamics AX, and specifically when it's only a spoke in the total solution, such needs exist. Further such possibilities exist, with Dynamics AX 2012 R2, out-of-the-box no other software required!

Well that is all for this post. There is a lot for us to continue to talk about, specifically and we continue down our path of further and further creating Systems of Engagement for Microsoft Dynamics AX customers. Til Next Time!
Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

AX 2012 - Using Active Directory Groups for Security

I wanted to spend a little time in this post, to focus in on somthing that I don't think has had a lot of coverage, but is somthing worth while to note. You have seen me post, in the past about security for AX 2012, with the following.:

• AX 2012 - Security Development Tool (Beta)
• Microsoft Dynamics AX 2012 and the use of Claims Based Security
• Microsoft Dynamics AX 2012 - Security Architecture Overview
• AX 2012 and the use of the new Extensible Data Security Framework
• AX 2012 - Security Model Design Considerations
• Ax 2012 and the impact of Design with the new Security Model
• AX 2012 - Hiding a form control withut code
• AX 2012 - Security Tools Review

Well today, I wanted to spend time on this topic again, and focus back on the fact that you can make use of Active Directory Groups when creating user accounts inside Dynamics AX 2012. I'm not talking about the import process by AD Group, which is possible and speeds things up a bit. No, I'm talking about assigning a User Account Type of Active Directory Group.

We start by going to the System Administration module, Common, users, Users form. In doing this, we need to click on the new user button that you see in the image below.:



In doing this, we should see a screen similar to what you see below, which is from the Public Sector, demo image for AX 2012.



Now that we have this form openned, we are ready to add our AD group, user account type. It's important to point out, that you must start with changing the account type on the form to Active Directory group as shown below.



Now that we have this, and have selected the desired starting legal entity, we can move to setting the user id, which is the internal user id used in AX 2012 that is assiocated to every transaction done by someone within this group from Active Directory.

Filling this out, next we want to enter in the Network Domain, and finally the Alias that is used within AD to identify the group. Since we are using the Demo image, we will make use of a group from Contoso.com. I'm going to make the choice of CSHelpDesk, in this case. In doing this, and filling out the form, you should see something similar to the below.



Notice, that the user id for this AD Group is set, along with I've assgined a Security Role to this AD Group. This Security Role not is applied to all users within the Active Directory Group. Further, what needs to be understood, is that user options as well as Role Center profile assoication is now tied to the AD Group vs. specific AD users.



With this, we can see how an Active Directory Group can be assigned security rights within AX 2012. However as you can see from the above, things like internal user id for AX, user options & Role Center profiles are not actually AD user specific in this setup. Further, user relations as it relates to employee information, becomes disconnected and not possible. So you have some considerations to keep in mind when you make the choice of using Account Type of Active Directory group vs. Active Directory user.

Well that's all for now, check back soon as more to come. Till Next Time!



Top 100 Update: I did want to take this time, at this end of this post and say I'm Honored to have been listed again in the DynamicsWorld.co.uk Top 100 most influential people in the world for Microsoft Dynamics. This year I was ranked 19! Congrats to everyone on the list and it's my honor to be listed among such great people. The work that everyone does to build this community, always encourages me! A direct link to the ranking can be found here.: Top 100 - Brandon George - 19


Visit Hillstar Business Intelligence (www.HillstarBI.com) in order to truly unlock your data trapped in your Microsoft Dynamics investment. With our value driven business intelligence strategy Hillstar help you transform into a data informed company.


Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - Security Tools Review

I hope everyone is doing well this week, and finding yourself in a very productive mood, diving deeper and deeper into your AX projects. I wanted to take the time, and highlight an Context Menu Add-in, for AX 2012, specifically the Security Tools that appear when highlighting certain objects in the AOT.



When talking about security in AX 2012, it's important to understand what securable objects within the application are related to what Duties, Roles and more.



To help us understand how the secureable objects in AX 2012, are related to specific privileges, through duties and roles, Microsoft comes with out-of-the-box offerings, that help us in this effort. This is what we see in the first image of this post, showing where, highlighting for example, the SalesTable table object, right clicking and then highlighting security tools, and finally clicking on the View related security roles. In doing this action, a similar screen as shown below is displayed.



There are many fields in this, for helping us understand how the specific element we have highlighted, related back up through the security model in AX 2012. As the following screen shot, further shows even more of the helpful information, for understanding the securable objects relations.



You can see, that like any other form in AX, that has a grid control, you can filter by grid, to get to needed specific information, like type of security, if it's related to form controls, etc. What's also great, and this is again throughout the AX application, the ability to take the data within the specific grid control, and easily export that to Excel, for further analysis and reporting.



Clicking on the export to excel, and we can see quickly and start working with the security related information for the element.



This then, helps in the design phases, as well as post development, within the operation of AX, to understand and glimpse into the current setup from the Role, down to the duty level of the security artifacts that exsit now as part of any AX 2012 instance. This again is powered, out-of-the-box, through the content menu. You can better understand what other functions exists as part of these Security Tools context menu in AX 2012, by going to the Menu's node, in the AOT tree. From there navigate to the SysContextMenu element, and expand the Security Tools node.



With this information, understanding what exist around security for specific elements of AX, be that out-of-the-box or custom, becomes a lot easier. This translate further, into helping make the term, powerfully simple, a true one. To add more value to this topic, if your interested in understanding more about how to work, and add your own scope to the context menu in AX, I recommend checking out the following resource page on MSDN: How to: Add Items to the AOT Add-Ins Menu [AX 2012]

Well, that's all for this post, check back soon as I have a lot more coming, including the continue dive into AX 2012, BI, Data Management, Services, Ecosystem and a whole lot more! Till next time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - Hiding a form control without code

With Microsoft Dynamics AX 2012, the whole concept of Model more and code less is in full affect. The idea behind modeling, is that you cut down on the need to create custom code, to achieve needs. This is a great overall concept, and we are seeing this in Workflows, and well as Security.



So taking this to heart, and running with it, lets say you have a request to hide a form control, based on some context. Lets pick a functional one, in that we don't want users, who have read only access to a form, to see a specific form control.

In the past, real simple steps could be taking to do this, and a popular way of handling such a request, would be to (a) Make sure the control had AutoDeclaration set to yes, and (b) override the init() method of the form, and work with the forms .visible() property. This would be based on either, say the company, or a security key in the pre-AX 2012 days.

This however has changed with AX 2012, and we can achieve this need, without any code actually. How you may ask? Well check out the following Microsoft resource: Security Permissions Properties for a Form [AX 2012]

"To see a particular control on a form, the user must have a permission to the control that is at least as strong as the permission the control requires.
For example, suppose a control has its NeededPermission property set to Update. A user who has only Read permission does not see the control on the form. But the control is visible to another user who has Update or Delete permission to the control."

So lets explain this a little bit then, shall we? To start, we have a need Permissions node that lives under the form objects now.



With this, we see, as mentioned in the above resource, the Read, Update, Create and Delete Permission nodes. Each of this are in order of weakest to strongest security. In that, if a user has a privilege that enables them to have Read access to the form, and then control had the needed permission of Update, the user Would not see the control on the form. Since this is the desired scope, then we understand how we can relate privilege's to NeededPermission.

When looking under these nodes, you would not drag or drop controls under each. Nor do you create new elements, under the Controls node. If, we want to take a control, and have it's NeededPermission to be set as Update, then we must go to that Control, open the properties, and set the NeededPermission value as so.



On saving of this property change, we can now see that under the Update node of the Forms Permissions, contained within the Controls section, we see now our 'Control2' has appeared.



Now through proper security setup, when users only have Read level permissions to our form, they will not see the Control2, form control. So we have used security modeling aspects of AX 2012, and not code, to enable the visibility of a control on a form. Pretty powerful huh?

Well that's all for this post, I hope this helps someone out. Keep checking back as we continue to dive more and more into AX 2012.

Till next time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"