I work with an Excel add-in called SAP BEx Analyzer (BExAnalyzer.xla).
Unfortunately, the documentation of this add-in seems very incomplete and it's a pain to work with it.
I would like to know if there is a way to inspect such an add-in to see what objects/methods/function and so on it contains?
Many thanks!
In the current release of SAP Business Explorer (based on 7.30), the BExAnalyzer.xla file is unprotected so you are able to inspect it.
If you wish to delve deeper in to the BEx object model, it is worth adding a reference in your VBA Project to the two type libraries (BExAddin.tlb and BExApi.tlb) in the Business Explorer installation folder (usually located in \Program Files (x86)\SAP\Business Explorer\BI\).
I'm actually in the exact same boat with BEx. I haven't found any official documentation but a hefty amount of google fu gets me by. I've also had some luck pressing F2 in the code window when you have the SAPBEX.xla module selected and then picking the SAPBEX library in the first drop down. It will give you all the methods/functions/constants in the library which isn't documented well at all either but you can make some educated guesses and trial and error...if you have the spare time.
Related
Is there a way of storing VBA source code that's common and accessible to all Microsoft Office products..? I have a variety of functions which I use in both Access and Excel, and sometimes even Word. I modify and add to the the functions and modules frequently. The copying, pasting, and maintaining of code between projects can get tedious, and I inevitably overlook something.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
If there was a way to store VBA code in independent files, and open them with the VBA IDE in a standalone mode of some sort, that would be outstanding, but I know the IDE doesn't work that way...as far as I know.
I know I could do something like write a class/ocx/addin in VB6 or DotNet, compile it, and reference it in my VBA projects, but I was hoping for something more simple.
Unfortunately that's your best bet.
As you know VBA code is hosted, wrapped-up in a host document: a VBA add-in is still tied to its host document (.xlam, etc.), and as such can't be shared with another host.
In VBA-land what's meant to be shared between VBA projects, is type libraries - things you compile separately from the VBA project, and reference from as many projects as you like.
If you have a VB6 IDE, you can compile a 32-bit DLL that VBA projects can reference. The problem is that it won't work with 64-bit hosts - the solution is a .NET type library, written in the .NET language of your choice, made COM-visible. Note that COM-compatibility does restrict what you can expose in your API: for example you can't expose generics, and method overloads will look weird.
If a type library isn't an avenue you wish to explore, then your choices are rather limited, and IMO sub-optimal.
IMO the only thing that can "work" is a bunch of exported code files in some common folder, and the VBA projects that need to use that code need to literally import these code files. The risk here being, that if you make any changes, other VBA projects using an unmodified version of that code will not "see" these changes, IOW by doing that you're multiplying the number of times you need to fix a bug by the number of projects using that code.
Or you could have some code that uses the VBIDE extensibility type library to ensure the set of imported modules always match exactly with the exported files in that common location.
If you want to use VBA in the same Office program (e.g. one Excel file to another, or one Access file to another), you don't need to use any special kind of file. You can add a reference to an external database or worksheet with macro's enabled.
Navigate Tools - References - Browse - Excel/Access file - Add the file
See the following screenshot:
You can't use files across different Office applications this way, but you shouldn't. Each application has different built-in functions, so your code is likely incompatible anyway.
With newly released Webi there's no way to manipulate reports with VBA like it was in DESKI era.
I'd like to know if there's a way for me to click a button with parameters in Excel sheet and get a report from the server?
I've been thinking of using the RESTful Web-services but it seems that there is a performance problem.
I also considered using a JAVA app in the middle using the SDK but it's not really satisfying as I add one layer.
Do you know if there's an other way to download a Webi report from and to Excel?
For this type of requirement, you'd normally use the OpenDocument feature. There is one thing that it won't do however, at least not for Webi documents, and that is deliver the output in Excel format (HTML and PDF are the two possible formats for Webi). In all fairness, the export to Excel option is only about two or three clicks away, but I can understand that this wouldn't be an ideal solution.
Another option is the Java SDK, which I would not recommend, as the ReBEAN SDK (the part of the Java SDK you need to interface with Webi documents) is deprecated and replaced by the REST SDK.
The REST SDK would be the way to go if the OpenDocument feature is not sufficient. Keep in mind that this would involve quite a few steps, each time sending a command to the WACS server and then decoding the answer. The steps would be:
Authenticate and get a logon token
Refresh the document (if necessary pass prompt values)
Export the document to Excel
Close the document
The REST interface is only supported on the WACS server, which should run on your BI4 server (unless you have a customised landscape). If it's slow, I would suggest looking into the root cause of this performance issue, instead of discarding the SDK altogether.
If you're going to use the REST interface, I would recommend opting for JSON to communicate through REST instead of XML. It's easier to read and parse.
A last option, which I wouldn't recommend, is LiveOffice. This is a separate product which allows you to embed contents from Webi documents into Office documents (most notably Excel). LiveOffice has always had its share of problems and has not received much love from SAP regarding much needed updates.
One final thought: the report will never appear in the same sheet, at least not without an additional amount of coding. Whatever SDK you end up choosing, you will always end up with an Excel file. If you want to show the results in the Excel file you started from, you'll need to code the steps to open the generated file, grab the contents and then copy those to your worksheet.
I have a method which downloads sharepoint documents to the local disk. I use SPFile.OpenBinary() method to get physical file, but it contains all fields of a parent DocumentLibrary. Does anybody know how to clear file (doc file) from these fields? I found only way to do it using Word interop library (method described here http://maxim-dikhtyaruk.blogspot.com/2009/05/trim-sharepoints-documents.html), but it doesn't fit my requirements cause it works only when Microsoft Office is installed on the machine...
You may want to read this to understand whats going on.
I do not know if this can be turned off or not, but it happens only with Word 2007 documents (docx).
You could do any of the following to turn this off:
Create a new content type and associate it with a document library. Use this document library from now on.
Look into some Open XML library or the Open XML SDK published by Microsoft.
This isn't a bug, it's supposed to be a feature! :-) Seriously though, you need to edit the Word document programmatically to remove these additional fields completely (I think even a content type will leave some behind).
For documents prior to Word 2007, you could use a toolkit like Aspose. I almost needed to do a similar thing once and would have used this product to do it. I'm sure there are other options out there.
For Word 2007 and higher, as SharePoint Newbie says, you should be able to use the Office Open XML formats to edit the document. Here's an MSDN intro article.
I made a discovery some time back. Just follow these steps:
Create a .doc/.xls/.ppt file in office 2003. Keep some test data in there and close the file. Now rename the file to change it's file extension to a random string, taking care that it is unassociated, like test.asdfghjkl etc.
Double click the file and it opens seamlessly in the parent application.
Now AFAIK, windows checks the file extension of the file and uses it to do an action, viz open an application and pass the file to it to open. Then how does the office suite manage to do this?
EDIT: How about the case when the extension is changed to one that is associated with another application. Is there a priority algorithm in place for handling that ?
Do you have the "View extensions for known types" option on?
EDIT: #Comments....
Yes, its a stupid/insulting question, but when troubleshooting a problem I have learned to assume nothing, and trust the users 0%.
BUT, I tried it, and you're right. Its stupid that MS has this kind of behavior, and it can only lead to security vulnerabilities, which led me on a search for your answer.
From the posts at http://seclists.org/fulldisclosure/2007/Jan/0444.html
"You have stumbled on an age-old
quirky behavior of Windows. Office
document formats are based on a
standard Windows container format, OLE
structured storage files, also known
as "docfiles". A docfile's name and
extension are irrelevant - the file
is, conceptually, a serialization of
an OLE object, and like all
serialization formats it contains the
identifier of the application that
produced it, in the form of an OLE
class id (in GUID format) in this
case. You can easily verify that it
doesn't work with the newer Office XML
formats"
Indeed it doesnt work for the 2007 *X file types, but 2K3 is still a problem. To solve this problem... Upgrade! =)
And here at security focus under TOC point 2.
So, there you go.
I can't seem to make this happen now, but I know I saw Windows reading XML processing instructions a few years back. Maybe that is what's going on?
I am stuck with a problem
The Requirement is that, there a complex Excel file(XLS) that is used as template; it has Macros and all the worksheets are either locked or hidden. When the user clicks to download it, the follows operation occurs
Unlock a particular worksheet, fill some data # certain cells and then lock it back.
Unhide a worksheet, fill some data # certain cells and then hide it back.
I think there are two options to resolve it (if there are more then please let me know)
Interop libraries / Excel Object Library
OLEDb Driver
I cannot got with the option 1 as excel is not installed on the webserver and I heard that it's not a good option to install MSOffice # webserver.
My question is that can we use OLDb to perform the operations mentioned above OR is there any other option ???
BTW Sharepoint service is also not available :(
Please help!!!!
You could maybe try ExcelPackge.
See this article:
Server-Side Creation of Excel 2007 Files Using .NET 3.0 and Office Open XML
see also:
Office Space - Building Office Open XML Files
Check out this question I asked some time ago for an overview of options. I ended up going with the Aspose library, which I link to in my original post. It's not cheap, but it does the job very simply and elegantly. It even has templating functionality built in (called SmartMarkers, IIRC).
SpreadsheetGear for .NET will handle this and has an API which is very similar to Excel. You can see what our customers say and download the free, fully functional evalution here.