Setup and Customization of an Axapta Enterprise Portal.

Yesterday, I tried to collect some of EX-Project experiences and skill in Microsoft Dynamics, I have worked few months ago to setup and Enterprise portal and then to customization of the same portal. At that time it was really fresh and new experience for me particularly with limited help on 4.o version. It was self learning experience and that's why I thought to drive the same experience but with latest version of SharePoint (MOSS 2007). I hope it will be a good start or reading for any new comer in such domain.

Steps need to perform as pre-requisites for setting up Enterprise Portal.
1. Have a look to below prerequisites before you start setup process.

1.1 http://msdn2.microsoft.com/en-us/library/aa493471.aspx, visit the link to see setup guide of MS Dynamics Ax 4.0

1.2 Verify the components installed, and make sure Enterprise portal and supportive components are available to use.

1.3 Make sure other supportive server implementation have all services packs and updates in place if applicable.

1.4 For using reporting services with EP you must to ensure reporting services are well configured and ad-hoc reports also have proper configuration.

1.5 Also it is advice able to uninstall Internet Explorer Enhance Security Configuration.

2. Create Business Connector Proxy account in DC, make sure you create an account with flags like password not expire and to keep more security measures for proxy account you can also flag no interactive rights. You must give following groups right in order to make sure the account works for Business Connector.
IIS_WPG
WSS_WPG
Also it needs any other custom groups if you have plan to access such information falling under those groups inside EP.

3. SharePoint portal or WSS site should have .NET 2.o configuration in IIS.

4. Proxy account which we created for Business connector should have login access of SQL Server as well as it should have dbcreator server role.

5. Configure SharePoint site as integrated windows authentication, you can change the configuration by routing to Application Management -> Application Security -> Authentication Providers. It will list all security configuration, by default it will display 'default' label, you can select active configuration and change to Integrated Windows Authentication with NTLM (EP Portal don't support Kerberos delegation method).

6. Select the application pool in IIS on which EP portal is going to run, check the properties and then Identity tab, change credential to proxy account which we created for business connector. Always rebounce the IIS after any change in contexts by using iisreset /noforce.

7. Open the web.config file of SharePoint file and make sure trust level is WSS_Medium if not then change it to WSS_Medium, you can have custom level of security configuration on need and requirement. It is also advisable to give executionTimeout configuration for 6000 ms for httpRuntime calls.

8. Add below webparts into safecontrol so SharePoint site can use them without any obstructed. IF you are using any custom webparts please make sure they are also listed in safecontrol tags. Recycle the IIS Process after web.config update by using iisreset /noforce command.

Steps for deploy Enterprise Portal.
1. Drive to Enterprise portal configuration wizard (Administration > Setup > Internet > Enterprise Portal > Configuration Wizard), click on wizard and then click on Next button.

2. Configure user groups and map them to Enterprise portal groups. Make sure the customized groups are correctly mapped into Enterprise portal.

3. on next screen you need to give credentials for Business Connector, you can supply proxy user which we have created for Business Connector.

4. Next screen will ask you to map documents type to document categories in Enterprise portal.

5. On fifth screen you need to configure module documents categories.

6. Next wizard form will ask you to configure document movement, number of days that document need to include in the list of latest documents etc.

7. Configure transaction summaries.

8. By clicking on Next Wizard you will be diverted to Enterprise portal deployments wizard if it is already been deployed and you will be diverted to Manage Enterprise Portal Deployment forum (GO to step 11 else follow order). Check below screen to refer deployment wizard.



9. Next screen will ask you to mentioned IIS virtual directory and SSP site to deploy metadata and EP components. Here you can select option for deployment like if you want to use only webparts then you can select webpart deployment that will enable site to used deployed webpart. By selecting full deployment you will get site templates which will be useful to create site collections under Enterprise portal and pre-generated pages for all system objects. Refer below screen.



10. By click on the last page of the wizard you can finish the deployment as well it will give you two option if you want to restart IIS server after deployment and SharePoint new site wizard (SharePoint admin site).



11. Below you can see Site collection form to create and configure new site. Check at the template section where you can see under the custom template tab that list shows Enterprise portal templates which we can use to create portals.



12. Cross your figures and it everything went well in previous steps then you will find the below screen as a success. :-)



13. If the user you are accessing is not registered or mapped under the Axapta then you will see below message.



14. You can setup the relationship between web user and Axapta user by user relationship form (Administration -> Setup -> User relations). Map the user to correct Axapta user.



15. You can also configure site URL to internal website group.



16. Bingo... Now it's done... You have now setup the site and portal.



This article mentioned to create website portal in general scenario you might need to change or perform more steps in order to deploy enterprise portal in working order in different scenarios and needs.

The default deployment will give you all pre developed web solution and interactive pages inside portal. Obliviously every organization needs customization in portal in order to streamline the Axapta main installation customization to streamline portal and native implementation. It is very important to understand Ax, X++, AOT, AOS and development interfaces inside Axapta client to make that customization possible. Main components need to incorporate for streamlining such customization are changes in Data dictionary, functional default processes and data ownership and security. Changes and implementation in native Ax rollout are not automatically going to enterprise portal. You must ensure the same customizations, changes are been implemented in web solution and components and they both went live on the same point of time otherwise it could create complications and integrity issues with present and new data. As within this article I am not covering such practices but given high level idea before any customization with portal.

Customization of Enterprise portal in Axapta.
1. Below you can see the AOT (Application Object Tree), AOT displays entire object model of Axapta like classes, objects, forms, website (web forms, weblets, menus, urls etc...). You can directly add, update and delete that object and start customizing the product from AOT only. But it is not advisable, it's always advisable to take backup (export *.aox) of those target models and object which we are planning to change. Then using projects window you can add new forms and customization which will give you better control over changes and customization.







2. After customization you can compile project or root element of AOT Tree (if doing direct level customization), refer above image which shows in bottom pane about compilation results.

3. After compilation, changes should deploy through manage deployment form (Administration -> Setup -> Internet -> Enterprise Portal -> Manage deployment). IT will give you the control about which associated and register site should receive the recent updates. Unfortunately there is no such versioning and source control available for such changes and deployment, so always it's good practice to export customizations and take the backup and archive those export files (*.xoa). By clicking update button on the screen it will deploy the changes on the sleeted servers and will show deployment summary in new window as seen in below screen.



4. After deployment you can find such customization (new menus, urls, links, and form etc objects) in the list properties of different Enterprise portal’s webparts.



Here in the article, I haven't gone deep inside about the customization. Will defiantly try to come-up with new detail article about the customization of the Enterprise portal.

Hope my article helps you in any manner to understand the process, please share your views and send your feedback to nilayparikh@gmail.com

Call outs (Plug-in)/CRM Adapter Vs Ajax Calls for Microsoft CRM integration

Recently, I have been undergone with experimental investigation during my CRM exploration drive with CRM 4.0. To design event driven data receive from Microsoft CRM, we can use some of in-house functionalities like Workflow, Callouts (Plug-in for 4.0 Version) and BizTalk (CRM Adapter/SOAP Adapter - CRM Web Services) but with these all methodology we are creating extra overhead on CRM Server only. I trial with my laptop and VS 2008 to create such scenario and compare results between different implementation methodologies and I found very interesting results.

My System Configuration is Turion x2 64 1.9 GHz with 4 GB RAM, this system I have used for the excremental drive. I have dedicated virtual PC to CRM and bombard through VS 2008 test agents and generate real-time scenario of 10 active users which I can say equivalent to standard production servers configuration and 100 active users for any SMB organization.

Workflows / Plug-in(s) & Callout(s):

I found some interesting results, first let me go through workflow options, workflows are basically design over the land of Windows Workflow foundation and they follow the same process like custom plug-in(s). I tried to integrate different entities and their data using event driven BizTalk SOAP calls. Workflows have very high latency (more then 4 minutes approx) and also they are very resource consuming, I found my processor was used more then average 65% and some time it picked 100 % utilization. It's oblivious that workflow will be slower as CRM itself takes 30-60 sec to invoke workflow after an event as well as workflows have been called by in process .net assembly (similar like call out assembly) so it would be slower and resource consuming option.
Advantages:
- More control over the Integration.
- Stronger security.
- Collaboration integration.
- Custom composite messages and control over message build
- Synchronized and asynchronized approach, gives flexibility.
Disadvantages:
- Higher latency.
- Resource consuming.
- Slow

CRM Adapter:

CRM adapter is general practice for integrating Microsoft Dynamics CRM to external world. It is quite easy and quicker to building solutions. It allows you to fetch all entities in the standard schema format as they have in Microsoft CRM. Let's back to performance, as it relay on different mechanism then workflows and callouts, it talk with SOAP services (Web Services) in CRM so it's bit quicker the previous option but it also generate process overhead on CRM server/databases to fetch data. The same amount of resource utilization i observed for CRM adapter.
Advantages:
- Easy to design and develop schemas and messages.
- Quick development.
- Faster then workflow(s) and plug-in/(s)callout(s).
Disadvantages:
- No control over message structure.
- Only support asynchronize method.
- Resource consuming.

Ajax Calls (Java Script calls):

'AJAX' is very fancy term but believe me it has same qualities inside implementation. Asynchronized JavaScript and XML (AJAX) generally used into web development but it have very large scope of implementation across various scenarios like such client face integration to Servers. I would like to elaborate such functionalities I have implemented in past and the result with this excremental drive. Supremely, it works really well with such load and handling such great traffic of requests without any failures and heavy latency.


img. 1. AJAX WS* Call

In above code you can write the synchronize post method as well as asynchronize post method, as in my organization we are using only IE for CRM client such Microsoft active x object works well with it.
Advantages:
- Very quick as it been called by client side code.
- No overhead for integration on CRM server.
- No read call back to database and CRM Server (unless you require to fatch GUID PK, still they are manageable with advance coding in java script)
- Full control over the message and schema, you can build custom schemas and message as per organization need.
- Full control over process, it support synchronize and asynchronize methods.
- Easily we can develop such bespoke services to plug into existing infrastructure.
- BizTalk and other Integration tools can easily connect without any third party components or services as WS* are standards.
Disadvantages:
- Security, need to provide enhanced security features, if it's called and manage by internal domain then it would be not issue.

Personally, I believe all methods and technologies have advantages and disadvantages; it's up to us what we select as best for the scenario.

Hope you like this article, please give your feedback to nilayparikh@gmail.com