splitting xpo into multiple xpo files

Question

Is there a tool that allows an xpo file to be split into multiple xpo files? The exact opposite of what CombineXPOs does.

The reason I'm asking is because I need to put multiple single xpo/models releases into source control and I want to avoid having to import them first every time as that's too time consuming.

I've created a tool to split xpo files to solve my problem. If anyone wants it, leave a comment. — AndyD, Feb 11 '15 at 14:10
Hi AndyD, Can you pls share the same. I am using AX 2009 SP1 RU8. Thanks in Advance — Vikas, Jun 02 '17 at 06:20

Alex Kwitny · Answer 1 · 2015-02-10T17:14:04.443

3

After understanding I think a bit more of what you wanted. Here is a job that gives you pretty much most of the examples of how to do what you want.

Note the TODO's that need completed.

static void JobImportXPOs(Args _args)
{
    SysVersionControlSystem vcs = versionControl.parmSysVersionControlSystem();
    SysImportElements       sysImportElements   = new SysImportElements();
    TmpAotImport            tmpAotImport;
    Filename                fileName = @"C:\Temp\testXPO.xpo";
    SysVersionControllable  controllable;
    TreeNode                treeNode;

    sysImportElements.newFile(fileName);
    sysImportElements.parmAddToProject(false);
    sysImportElements.parmImportAot(true);

    tmpAotImport = sysImportElements.getTmpImportAot();

    while select tmpAotImport
    {
        treeNode = TreeNode::findNode(tmpAotImport.TreeNodePath);

        if (!treeNode)
        {
            // New object being added to AX
            // TODO - Remember this object and add this to VCS system at the end for check-in
            continue;
        }

        controllable = SysTreeNode::newTreeNode(treeNode);

        if (!controllable)
        {
            error(strFmt("Error processing %1 (%2) from file %3", tmpAotImport.TreeNodeName, tmpAotImport.TreeNodePath, Filename));
            continue;
        }

        if (vcs.allowCreate(controllable))
        {
            info(strFmt("Planning to add to VCS %1 for import", tmpAotImport.TreeNodePath));
            // TODO - Remember to add this to VCS at the end of the import
        }
        else if (vcs.allowCheckOut(controllable))
        {
            info(strFmt("Checking out %1 for import", tmpAotImport.TreeNodePath));
            // TODO - Remember to check this specific object back in at the end of the import
        }
    }

    // Do the actual import
    sysImportElements.import();

    // TODO - Check in all of the objects we just handled

    info("Done");
}

edited Feb 10 '15 at 17:14

answered Feb 09 '15 at 00:03

Alex Kwitny

11,211
2
49
71

I did see that tool, but it's from 2006. Has the xpo file format not changed since then? I have xpo's for every version of AX 2012 with slight differences between them. To import each xpo and export using above code would take too long. Hope that makes my problem clearer. – AndyD Feb 09 '15 at 02:08
You still haven't clearly explained the problem. So you have one XPO that has many objects in it, then you want to turn that into multiple XPOs of the individual objects? Import the one giant xpo and create a project full of the objects, use the sample code I provided but obviously modify it to crawl over the project node and dump each object out as an XPO and you're done? – Alex Kwitny Feb 09 '15 at 19:52
The problem is time. It would take days to go through every single release of AX and every bugfix for the software I'm working on. Splitting the xpo outside of AX or a VM would speed things up massively. Just image having to do what you described 20+ times... mind numbing. – AndyD Feb 09 '15 at 20:46
The reason I need to split it up is to put the code into sourcecontrol just like AX would do it. – AndyD Feb 09 '15 at 22:28
Wait. Are you thinking that you can take a flat XPO file and split it into different previous versions? You can have an XPO that contains `Tables\SalesTable` and `Tables\CustTable` for example, but not `Tables\SalesTable (Version 1)` and `Tables\SalesTable (Version 2)`. So isn't your source set of XPOs the latest version? You can import them via script with a command line switch `–aotimportfile=` (https://technet.microsoft.com/en-us/library/aa569653.aspx) – Alex Kwitny Feb 10 '15 at 00:26
No, that's not what I'm thinking. I have an xpo for every single release. I'm trying to build up a change history and commit the differences between each release to our source control system. I have written an app now that splits the xpo and recreates the same structure that AX creates when you add a model to source control. If there's a command line tool that already does this, i.e. the opposite of CombineXpos then I would rather use that of course. – AndyD Feb 10 '15 at 09:41
Sounds like a minor, one-time pain, but if you know the import-order of files. SalesTable_1.xpo, SalesTable_2.xpo, etc, then create a temporary table in AX with all of the filenames, integer sort field, and boolean `processed` field, then just write a job to loop over un-processed records, import the XPO and if it is not in VCS add it, then check-in, then mark as processed. If it is in VCS, check it out, import it, then check it in, and mark as processed etc. That'd probably be the best way to build it up. I think if you actually add the files to TFS, you would have to script the check-in/out – Alex Kwitny Feb 10 '15 at 15:42
I think if you add the files to TFS, you'd still have to script it somehow, and then have to do a get-latest in AX. Building-up the changes is the hard part, because the XPOs appear to be the same version for any given object most likely. That plus you would want to keep your entire version history, not just object history. I.e. V1 might be SalesTable & SalesLine, V2 may only be just SalesTable. If you were to do it object-by-object, then you might do V1 SalesTable, V2 SalesTable, V3 SalesLine. And then the object history would be there, but not the true system version-history. – Alex Kwitny Feb 10 '15 at 15:44
That's a big issue that I think you're not seeing as well. Check-ins are often multiple objects at once. NOT just one object. So you wouldn't be able to pull an entire version. You would only be able to see the change history of individual objects. Now if you are just "basing" your VCS then this wouldn't be terrible, because going forward you would be in better shape. – Alex Kwitny Feb 10 '15 at 15:46
Thanks for your updated answer and your time spent. However, I've got a solution now which I can run from the command line without requiring AX which splits xpo files into the same structure as when you add a model to sourcecontrol in AX. I'm also using Git with SourceTree which I use to build up the history which works nicely as it's file based. – AndyD Feb 11 '15 at 14:06
As long as you figured something out. It was a positive exercise for me to script up anyway. I was curious how one flat file could be broken down and examined anyway. Best of luck – Alex Kwitny Feb 11 '15 at 17:10

splitting xpo into multiple xpo files

1 Answers1