Joe Kaufman Bell Laboratories Inc No longer there

Seth,

OK, I got some sample code, and I realize getting a specific file cabinet is not as easy as I thought -- I wrote some extension methods to make it easier.

Here is an extension method of an Organization object that can get you a file cabinet by it's ID:

=========================================================================================
public static FileCabinet GetFileCabinetById(this Organization org, string fileCabinetId)
{
    FileCabinet fileCabinet = null;
    if (org == null) return null;
    if (fileCabinetId.Length == 0) return null;
    List<FileCabinet> fileCabinets = org.GetFileCabinetsFromFilecabinetsRelation().FileCabinet;
    fileCabinet = fileCabinets.Where(f => f.Id.Trim().ToUpper() == fileCabinetId.Trim().ToUpper()).First();
    return fileCabinet;
}
=========================================================================================

Basically, if you put the above static method somewhere in scope (same namespace), then Intellisense will offer the method as an extension method of the Organization object. It would appear the key method built in to DocuWare is GetFileCabinetsFromFilecabinetsRelation(), but that returns all file cabinets. So, we filter the List of FileCabinet objects using LINQ. Here is the same thing, but it gets a file cabinet by name instead of GUID:

=========================================================================================
public static FileCabinet GetFileCabinetByName(this Organization org, string fileCabinetName)
{
    FileCabinet fileCabinet = null;
    if (org == null) return null;
    if (fileCabinetName.Length == 0) return null;
    List<FileCabinet> fileCabinets = org.GetFileCabinetsFromFilecabinetsRelation().FileCabinet;
    fileCabinet = fileCabinets.Where(f => f.Name.Trim().ToUpper() == fileCabinetName.Trim().ToUpper()).First();
    return fileCabinet;
}
=========================================================================================

I am not sure why DocuWare does not build in these handy methods to the package libraries, or maybe there is a better way and I just don't know it. Here is the help page on getting file cabinets, so I must have gotten my original code/idea from there:

http://help.docuware.com/sdk/platform/html/ee25973f-3c6a-456b-967d-a8b179881d3f.htm

Hope this helps!

Thanks,
Joe Kaufman

Seth,

You are trying to assign a string directly to a FileCabinet type. That's not going to work. A FileCabinet instance needs to be created with the "new" keyword, as in:

FileCabinet cab = new FileCabinet();

I am not sure if the constructor of FileCabinet can take a GUID string directly, but I am pretty sure it cannot. I think a file cabinet is created from an Organization object, but do not have my sample code handy until Monday.

Thanks,

Joe Kaufman

It also sounds like you are trying to use a string variable as a FileCabinet type, so your code seems to have some fairly serious issues...

Thanks,

Joe Kaufman

Seth,

When you have these errors, you need to provide the code that is erroring out. There is no way to debug without seeing the line that is erroring out and the lines around it. Also, is this a compile-time or run-time error?

I am on vacation until Monday, so if you provide a sample by then I can take a look. It sounds like you are simply supplying the wrong data type to a field as you are creating the indexes for the store. Make sure all data types match what the DocuWare cabinet is expecting.

Thanks,

Joe Kaufman

Wayne,

I don't know a lot about workflow, but I just downloaded an XLSX file via the Platform SDK service and it came down in its native format, not PDF.

What export are you using? That's the part of workflow I am unsure of...? If it is a call to a web service that uses DocuWare's own Platform Service, then it should download as the actual file, not a PDF conversion.

Thanks,

Joe Kaufman

Hey all,

UPDATE: I would still like someone to help with this if they can think of why it would be happening (so read further on for the original post contents), but I have had some success with a different HTTP request object. I tried using the straight XLMHTTP object, as in:

loRequest = CREATEOBJECT("MSXML2.XMLHTTP")

instead of what we have used previously for DocuWare (and for every other web service call we do from Foxpro):

loRequest = CREATEOBJECT("MSXML2.ServerXMLHTTP")

The classes are close, but from my reading, ServerXMLHTTP should be everything that XMLHTTP is, plus is more robust for server use. XMLHTTP is meant for client operations, though, and that is what I am using it for. XMLHTTP also appears to call things asynchronously, because after the Send() my code after would error out until I did a loop waiting for ReadyState = 4 (like classic web page programming/scraping -- you need to wait for the response to finish).

Even after waiting for the response, using XMLHTTP made downloads fast again, from 30 seconds down to one second for a 20 MB file. This means I need to add wait loops to all of my Platform Service-based Send() calls, but that should not be too difficult. Will see if everything else works as it should after switching to the XMLHTTP object. I still have no idea why ServerXMLHTTP started getting slow on downloads when it has worked for every other web call we do in Foxpro, and has been working for 5+ years in that regard.

=======================================================================================

(Original post below...)

I am not sure if it is a new issue (but it seems like it is), but downloading files from DocuWare is very, very slow in certain situations. We are talking over 30 seconds to download a 20 MB PDF, and in one scenario it took over 5 minutes to download a file around 100 MB (166 pages).

This only happens when I download files via HTTP Request "GET" calls to the Platform Service, and it isn't just Foxpro. If I use the very common HTTP Request console Postman, it takes the exact same (long) amount of time to download documents. The resourse/URL I am talking about looks like:

http://docuware1/DocuWare/Platform/FileCabinets/0C2C3278-FF61-42DE-AD0E-CD7BDB1677B9/Documents/471327/FileDownload

(I don't mind if you know one of my on-premise cabinet GUIDs.  *smile*)

The funny part is that if I download the same document via the .NET package in C#, the files download instantly. Larger files might take a second longer, but it is definitely not struggling the way non-NET requests are. Additionally, if I paste the above URL into an authenticated browser session, the downloads are immediate as well. I tested that in Chrome, Firefox, IE, and Edge, and the file downloaded instantly. Doing an edit in DocuWare, which obviously pulls the file down, is also fast.

If it were just Foxpro, I'd say it's just my problem. But it isn't just Foxpro, it is Postman, too. This HTTP GET request is dead simple, yet it takes MUCH longer when using Foxpro and Postman and scales horribly as documents get larger. Everywhere else it is fast.

Is there something on IIS I should be looking at? Or a log that might explain what is taking so long for one style of download but not the others? I am glad that some methods are faster (because I just switched to our external call to a DotNet wrapper exe I wrote just for this contingency), but also confused since I assume those faster methods use the same HTTP stack and same Platform SDK request. Could this be an issue with one of the DocuWare services struggling in some way? I am not sure which clients and which calls use which service.

I would simply bounce IIS (and even the DocuWare server) to see if that helps, but I can't while things are live during the workday. If I could discover the problem via a less brute-force method, it would be greatly appreciated! I am off next week, so I really only have today to work on this until August 20. I'd love to have this off my mind before going on vacation!

Thanks,
Joe Kaufman

Seth,

Nice. You will want to store the file cabinet GUID in the combo box, too (hidden column?) or use a ListView that can have multiple columns. Then, in the button click, check the index of the combo box and get the GUID. Then you should be ready to go.

I will be around more tomorrow but am off work all weekend and next week, so hopefully you get this working by then!  *smile*

Thanks,

Joe Kaufman

Seth,

In your button's click event, you cannot just reference "fileCabinet" if that variable is not in the Click event code. This is a "scope" issue. Each subroutine can only see the variables declared within it. So, unless you make "fileCabinet" a form-level member or property (that everything inside the form class can see), it will never generate any Intellisense and things will not compile. There is likely a red squiggly line under it because the design-time editor is saying, "I have no iidea what fileCabinet is in this context."

How do you display a list of available file cabinets? In other words, how does the List<string> called "fCabinet" manifest itself so you can select an actual file cabinet? Where do you load the names, and how do they display? If you just load those names in a List in one method, they are not going to be available to any other method. You need a form-level member that is a list of file cabinet GUIDs or something you can select/reference to choose the file cabinet to use. Alternately, you need a control on the form such as a ListView, as controls on the form can be references anywhere on the form since they are UI-related member classes of the form.

Once you have a real, instantiated FileCabinet object in that routine, the appropriate method will be available for it and you will be in business.

Thanks,

Joe Kaufman

Seth,

That is a method of a FileCabinet object. If it is not displaying in Intellisense then you aren't performing the method call on a FileCabinet object. There is really no way C# code can be wrong, because it won't compile if the objects are not of the right type. Can you post some code?

Thanks,

Joe Kaufman

Josef,

Sorry for the pain this has caused, but quick question -- everything hasn;t become case-sensitive, has it? Searches are still case-INsensitive, right?

I'm still on 6.11 -- another reason to stay there!

Thanks,

Joe Kaufman