Importing XML

5
I noticed that - when you import an XML-file - it's copied to the WEBINF\uploadedfiles folder (using a sequencenumber as a filename) when you browse to it in a Filemanager widget on some detail-screen for the xml-document (thanks to Fedor for showing me how to do it!). If you change the content of the source-file afterwards on the source system, this isn't copied. This makes sense when the importing is done manually. But with us, everything preferably is done during the nightly batchrun. From making the file in SAP to importing in Mendix. Given the behavior above, the old file will be imported in the Mendix-batch if you execute the import-microflow without having called the Filemanager to copy it to the server, not the new file. But you can only do that after it has been produced in the SAP-system. So it seems I need a programmatic way to call the file manager for that file and 'browse' to a fixed location as the first step in the import, I think. Am I right? Do you have a ready-to-copy example somewhere? The alternative, copying to WEBINF\uploadedfiles\n (with n being a - autonumber - number that might change if somebody does something in the GUI) isn't really attractive, I think. What's the (proven and riskless) practice here? Kees
asked
1 answers
11

You're correct that you'd need a programmatic way to let Mendix store the file for you. This way Mendix will take care of generating the correct file name and placing it in the correct location.

The alternative you mentioned, copying something yourself to WEBINF/uploadedfiles, is something you should never do, as this is very error prone. (The "uploadedfiles" location is not fixed but is configurable, the file name depends on object data from the database, Mendix could theoretically completely change the way files are saved in a next release, etc)

To instruct Mendix to store a file, you need to create a Java action containing something like the following code:

import java.io.FileInputStream;
import com.mendix.core.Core;
import system.proxies.FileDocument;
...
Core.storeFileDocumentContent(getContext(), FileDocument.create(getContext()).getMendixObject(), new FileInputStream("C:/test.dat"));

Obviously you'd need some more code for a full working solution, but the line with the storeFileDocumentContent call is the important bit here. After this line Mendix will have created a new System.FileDocument object for you with the correct attributes and file content. (By the way, there is also a corresponding getFileDocumentContent function)

One other thing: in the example code above a System.FileDocument object is directly created, but I'd recommend against this. Instead, create some entity in your domain model (in your case you could call it something like SAPImportFile), let that entity inherit from System.FileDocument and use an object of this type in your Java code and micro flows.

EDIT: I noticed you mentioned that the file you're importing is an XML file. If you're using this file as the input for an XML mapping, you'd need a System.XmlDocument object instead of a System.FileDocument object. Because these entities are related to each other, the above still works, just set the created System.FileDocument object as the value of the System.XMLDocument_FileDocument association of a System.XmlDocument object.

However, in this case there's a much simpler option that doesn't involve any Java actions: in a micro flow, create a System.XmlDocument object (or, preferably, an object that inherits from it). Next set the Path attribute of this object with the full (absolute) file name of the XML file generated by SAP that you want to import. You can then pass this object as the argument to your XML mapping.

answered