Perfil de Santosh KumarSantosh Kumar Paruvella'...BlogListasLibro de visitasMás Herramientas Ayuda

Blog


24 agosto

My experience with SL1 vs. BUS

This might be the known issue, but we suffered little bit, while working on SL1 and BUS features, and we resolved this issue after lots of research. I want share this experience with my blog readers.

My Issue is:

We are working for a client in BUS layer and my client suggested some features from SL1 and told us to do the customizations for SL1 features according to our functionality.

So we installed SL1 on top of BUS layer, we are trying to work on that SL1 functionality, but we are not.

We installed the same SL1 in standard version of Ax also (no BUS.aod’s in this one); in that environment we are able to use the SL1 functionality, but where as in SL1 + BUS dev environment we are not able to use the SL1 functionality.

After lot of research we found that most of the standard Ax objects are modified by the SL1 and Bus layers, due to this, SL1 functionality is overridden by BUS layer, because BUS is upper layer and SL1 is lower layer.

Then we had merged the SL1 functionality into BUS layer, after this we are able to use both the layers functionality.

The main reason behind this issue is, we didn’t get the Upgrade Checklist after we installed the SL1 on top of the BUS layer, because we marked the check box option for the Prevent Startup of the checklist, after initialization check list is completed successfully, when we did the Ax installation.

We didn’t see upgrade check list, so we thought, in SL1 they might have created all the new objects, like SYS layer objects, but after some research only we noticed that, they have done some customizations for Standard Ax (SYS layer) objects.

Dynamics Ax-EP Testing multiple web parts of same page

Testing of multiple web parts in EP development…

If we have a situation like, we want to host more than one web part in a single page, and we want to test that web parts before deploying into the SharePoint pages. [These web parts are like connected]

Assume that we have three web parts and we want to test that three web parts before deploying on to the same page

In our Development web parts - Visual studio solution, Move to the Design view of AxWebPartPage.aspx. We will find a control for testing a single web part.

Now move to source view of the same page, we will find the following lines of code for that control.

<dynamics:AxUserControlWebPart ID="AxUserControlWebPart1" runat="server"

                        ManagedContentItem="CplTmConflictSearch" />

Copy that control source code and paste it two times as follows and change the ManagedContentItem property according to the name of the web part names.

<dynamics:AxUserControlWebPart ID="AxUserControlWebPart2" runat="server"

                        ManagedContentItem="CplTmConflictSearchGrid" />

                       

                        <dynamics:AxUserControlWebPart ID="AxUserControlWebPart3" runat="server"

                        ManagedContentItem="CplTmConflictSearchRelationGrid" />

                       

Here I am testing that three web parts by using three controls of AxUserControlWebPart.

Now run the solution, we can see the result in browser direclty; if it is success then we can deploy these web parts onto a single EP page.

This way we can test multiple web parts of the same page.