AOD file is never reduced

(0) Share

Report

Posted on by Tulus Tobing

Hi AX experts,

My company purchased and implemented product builder in Dynamics AX 2009. One product builder id represent one finish good to be sold. If we want to use the product builder, we have to compile the product builder, and in the AOT it becomes a class with this format name : PBAExecutable_%1_%2
where %1 is companyId and %2 is the Product buiilder id (sequence number). When we compile, we must run the ax client with the layer as specified on product builder parameter.

In the beginning we decided to use usr layer to compile all product builder records. It started three years ago, and by today our usr layer file (usr.aod) has reached size 2.1 GB. I can assure you that it is because of product builder classes. We have 5 entities, and each entity has it's own product builder. By the format name I mentioned above you can imagine how many classes are created in AOT. If one product builder contain BOM, each BOM will be treated as one method.

A few month ago, we had issue with the cus layer file. Somehow we couldn't create any object, even one job. That job is displayed as cup layer but we can't run that job. The more we try, the more cup objects were created. We need to restart the AOS, and after that all the cup objects are gone.

Since we sell items that need to be configured through product builder, and sometimes we have to change the BOM of the item, system forces us to compile the product builder. But this cup issue won't allow these product builders to be compiled.

Daily operations must go on. We tried to ask the vendor, no satisfy answer provided. We decided to use another layer that is still available for us, which is USR layer.

Now the USR layer file increases, and it reaches almost the same with CUS layer. Just a few days ago, the same issue happen again. Everytime object is created in USR layer changed to USP, and we can't compile any object.

Now most of the product builder classes belong to both layer cus and usr layer, because of compilation requirement. We assume that AX 2009 has issue if the aod file reaches size more than 2GB. So we try to reallocate the classes to be compiled in cus and usr layer. We deleted discontinued product builder, and all unwanted classes are deleted from AOT. But the size of AOD is never reduced..I was wondering, why if create a new object and compiled the file size is increased but when the object is deleted from the AOT the file size is still the same.

At this point, at least we need solution to reduce the file size of AOD. But we couldn't make it.. Product builder is the core of our business. How can we reduce the AOD file? Or if you read the scenario above, what is the right solution for it?

Thanks,

Tulus Tobing

*This post is locked for comments

I have the same question (0)

All responses (5)

Answers (1)

Klaas Deforche 2,433 on at

Like (0)

Report
Copy link

Link copied!

Hi Tulus,

That's one big problem you have (2,1 GB big :).

Personally, I don't know if there are problem for large layer, I suggest you ask Microsoft.

I deleting object to reduce the size of the AOD doesn't work, you could setup a new environment without customizations. Then export only the objects you want to keep using an xpo and import them into a clean layer (with ID's). Then it's just a matter of removing the AOD en replacing it with the new one.

I don't know whether it's normal that the AOD file doesn't shrink, but it's creating a new layer is an option.

Exaclty how many objects do you have in your layers? Each layer has a range of IDs it can use (I think it's 10000). maybe you have 10000 object in your layer?

I'm just brainstorming here, I've never seen aod files that were so large.

Was this reply helpful? Yes No
Tulus Tobing 65 on at

Like (0)

Report
Copy link

Link copied!

Hi Klaas,

At the moment creating a new layer is an option I would do.

Below is the last id of cus and usr layer

cus: 45918

usr: 50977

The ado files are so huge because of the standard AX 2009 Product Builder module. Microsoft design that the product builder creates and uses the class in AOT to support the business logic.

The Product Builder module enables bill of materials (BOM) item configuration during the creation of: sales orders, purchase orders, production orders, quotations, and also determine the correct price based on user selection. Example one of chairs we sell can be configured to use available fabrics, finishing area, to apply interliner or not. These variables are dynamic and determined by users. Why we don't use the fix inventory dimension such as color, size..? Because it doesn't meet our business process.

One product model will have one class in AOT to handle the logic. If you see the last id of each layer I mentioned above, 80% comes from product builder class. So every time a new item is designed and ready to sell, a new product model is created. The same time a new class is generated by the system. That product builder works.

We implemented AX2009 when it was released in 2009. First year we didn't see this impact. But now in our 4th year, as the company grows we also sell the new product model. The new classes were created.

I think it would be fair, if AX can shrink the aod file when the object is removed in the AOT. Because when we release new product model then a new class is created in AOT by system, but when we discontinue the product model and manually delete the class from the AOT the aod file size is still the same.

Anyway thanks for your thoughts, I really appreciate it.

Thanks,

Tulus Tobing

Was this reply helpful? Yes No
Klaas Deforche 2,433 on at

Like (0)

Report
Copy link

Link copied!

Hi Tulus,

The number of items doens't seem to be the problem. I checked and you get an error when you go over it so you would know if you did :).

Also, I tried deleting a large number of object and the aod file doesn't shrink. I tried some things like flushing caches and deleting the aot, but no luck. The objects seem to be still in the AOD and the AOD remains the same size.

Michael Fruergaard Pontoppidan has some info about aod's on his blog:

blogs.msdn.com/.../new-layers-in-dynamics-ax-2009.aspx

If I understand correctly, they can go up to 6,5 GB, so this can't be your problem as yours are only 2GB.

I would suggest you set up a new environment, and only migrate the objects you really need (by xpo), then check if you have the same problems there. That should shrink you aod file, and that can never hurt.

Just make a project of your code and import it, or get the xpo's from you version control system if you have that and combine them using combineXPO (or sync with VC in that environment):

blogs.msdn.com/.../building-a-layer-file-from-xpo-files.aspx

Also, do you sometimes do a full compile of your code? That can never hurt either :).

Here's a list of general things I compile that you can do when nothing really helps:

www.artofcreation.be/.../problem-solving-in-ax

In your case, I would definitely stop the aos to remove the aoi, remove the auc files an do a full compile and data dictionary sync. But you probably already did that :).

I hope it helps when you create a new layer using xpo's.

Maybe let us know if you tried?

It's really strange though, I hope some other people share their ideas too :).

Best regards,

Klaas.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
Copy link

Link copied!

Hi Tulus,

In PBATreeNodeCompile class, method executableName change

ClassName executableName = classstr(PBAExecutable)+PBA::underscore()+stralpha(curext())+

PBA::underscore()+stralpha(_pbaId);

to

ClassName executableName = classstr(PBAExecutable)+PBA::underscore()+stralpha(_pbaId);

Delete axusr.aod file and compile all PBA models again.

You can export PBA classes from usr layer, delete and import to cus (var,...) layer.

(In Axapta 3.0 there was option to save PBA model to database.)

I also can suggest you to upgrade to 2012.

Best regards,

Ali

Was this reply helpful? Yes No
Verified answer

Tulus Tobing 65 on at

Like (0)

Report
Copy link

Link copied!

Hi Ali,

Deleting the axusr.aod or axcus.aod will cause another big problem. We already have some customization and important tables on both layers.

Also excluding the entity id on PBAExecutable class is also making other issue to our company. Each PBA record has unique behavior on each entity. We can't use one PBA class to be shared for all entities. I think it will also violate the main idea of product builder class.

But, thanks for giving suggestion anyway.

Just to update you, that I have decided to put all Product builder classes on separated layers. I chose cup and usp as the layer for compiling the product builder class.

AS OF 14 Jan 2013

----------------------------

We are unable to do any compilation on cus or usr layer. We really had a real big problem where we can't configure our product builder on sales order, sales quotation and purchase order. On the factory entity we are unable to send the order to production order.

The list of AOD files are seen below.

axcus.aod --> 2,5 GB

axusr.aod --> 2.5 GB

axsys.aod --> 775 MB

axvar.aod --> 540 MB

axsyp.aod -->79 KB

As you see aod above, cus layer and usr layer consists of customization + Product builder classes. We can't easily delete those layer and compiling the product builder from Product builder main form. Also on factory entity, to compile one class take 20-30 minutes due to dynamic BOM and we have around 1200 PBA classes. For your info 1200 PBA classes = 1200 Finish good that we sell to customers.

AS OF NOW onwards

-----------------------------

After spending much time to recreate fresh AOD without droping any data in live database and loosing any customization. Now in our live environment, we have managed the aod files as explained below.

axcus.aod-->28MB, consists only all existing customization made in cus layer since day 1

axusr.aod -->119MB, consists only all exsting customization made in usr layer since day 1.

axsys.aod --> 775 MB

axvar.aod -->540MB

axsyp.aod --> 79KB

axcup.aod --> 785MB consists only Product builder classes for some all entities except factory entity.

axusp.aod --> 3,1 GB consists only Product builder classes for factory entity.

I still don't have answer from Microsoft, why unlimited Product builder records can be created on the database and yet supported by the AOD that has a limited number of available IDs (and the file size I guess). We are as the customer only has two layers to work and manage product builder, and can force to utilize the patch layer (cup,usp) which in the beginning I would never touch it.

The product builder seems to be like cancer in our ERP system (Dynamics AX 2009), just the matter of time the aod file is growing larger and larger, we have to destroy all and give it birth again.

I also love the suggestion to upgrade to 2012 only for the product builder issue sake, but should we spend the cost only for this reason?

Thanks,

Tulus Tobing

Was this reply helpful? Yes No