I've been for the past few days trying to automate Siebel Web with Excel VBA.
With a combination of sendkeys and some webscraping, I've managed to query my data. The thing is that now I can't call the export applet in order to save it. I've searched almost every site that contains the tags "Siebel", "javascript", with no luck. Since IE developer tools are locked, I've used VBA to scrape the webpage, and tried to use Fiddler, again, with no luck.
I was wondering if someone managed to export data from Siebel into a xml/csv/excel file through automation.
I'll post my code later, in order to see if you could help me.
It seems to me that you would be better off using one of the Siebel API's for Java or COM. The COM interface allows you to directly integrate with Siebel using Excel VBA. It is a commonly used interface for extracting and updating business data.
It allows full access to the business layer, which includes the data sources, but also the process objects like Work Flows, Business Scripts, and other application functionality. It is truly powerful when you start working with it.
Keep in mind that you do need to be able to access the object manager port (2321) from the machine that the Excel file is running. In many corporate environment this is not allowed. So verify that you can beforehand.
Related
I am trying to create a data entry "app" to collect daily readings across our site. Here are the three biggest constraints:
Software - ideally, we would use some software within the Microsoft 365 Suite, mainly because those are the only approved apps on site. It may be possible to use open source software, but that might raise some flags in terms of security. So my thoughts are to use either Excel or Access.
Cost - ideally, we do not want purchase any additional software licenses. I would try and create something with Power Apps, but we do not have the licensing for an Azure or SQL server to store the data. I could be missing something here though.
Mobile-Friendly - finally, it needs to work on an Android tablet. Currently, we collect readings using pen and paper. The whole idea of this is to move towards using a tablet.
The easiest approach would be to create an Excel spreadsheet, save it on OneDrive, and edit the spreadsheet. I don't love this option because we are collecting 100's of data points each day. This would end up with a very wide spreadsheet that will be cumbersome to navigate.
The other option I looked into was creating an Access database and accompanying form and storing it on SharePoint. However, it seems Microsoft has stopped supporting Access databases on SharePoint.
I have created data entry forms using VBA, similar to this, but these do not work on mobile.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
I am engaged in just this kind of project also. I have written an app in PowerApps, built an Excel spreadsheet and stored it in OneDrive, and am running it (the app) on an iPad. The design differs somewhat from your description of directly presenting a spreadsheet to the user (which I think PowerApps could do) because I don't want users having direct access to the data.
Edit: You do not need Azure or SQL, unless you are storing tons of data. Excel can be a satisfactory data storage location for modest uses.
I found the learning curve for PowerApps to be quite steep, as it's a different paradigm than line-by-line coding.
I think this is a more user friendly way to collect data than trying to run an Excel form, and once you get it made and polished, you'll look like a pro :)
I am by no means an expert but if you need some tips I'll do what I can to help. It sounds like we are at similar developmental stages.
Is it possible to create a data entry form in Excel that also works on the Android version of Excel? Are there other alternatives I am not thinking of?
Microsoft Forms does the job when created from OneDrive on mobile browser. Side note: the form I just created and the response I submitted have now disappeared from my OneDrive.
I also saw some people using Power Automate to save responses from a form into an Excel file (every reponse).
I am running an automated Data job on a windows server that outputs a SAS dataset everyday. On top of this, I have an Excel Report connected via Excel's Local Data Provider.
My problem is, that the Data Connection needs to be manually refreshed by a person with SAS installed on their PC. I have tried writing a piece of SAS code that opens the Excel file on the server and then triggers a piece of VBA that did the refreshing, before closing and saving. This works perfectly if I'm logged into the server. But it doesn't seem to work if nobody's signed in. I believe this has something to do with having an active user session.
UPDATE
The process that I use to connect to a local data source from Excel, looks like this:
Data Connection Wizard
Select SAS Local Data Provider from OLE DB Providers
Add the Route to my SAS Dataset as data source
Select My source table and create a Pivot Report
Is there any way to do something like this?
When you want to run Excel unattended, thus no interactive user is logged on, you can do this with a Windows service. You have to ensure some settings for Excel, as well as it is important how you start excel.
Be aware of Microsoft does not support, or even suggest you to do something like this. Excel is a client software, it is exactly the opposite of a piece of software that is easy to maintain running as as service. Read this excellent article Considerations for server-side Automation of Office about the topic. Even when a little old (talking about Office 2003) it is still state of the art.
Please consider these conditions:
You cannot use the System or Network account, you have to let the windows service running under an account that at least have excel started once. This cannot be done with the named ones (as they cannot be used as interactive users)
Excel has to be opened at least once with the user under with the windows service account will run. You'll have to configure dcom settings, open vba once to initialize it, and most probably set some settings like "trust vba model" to be able to programmatically access Excel
last but not least when starting Excel you have to start it with loading the user profile. The Process.Start method in c# allows exactly that by just setting a boolean value to true.
Doing it like this, Excel should just start fine and update data connection with the VBA.
You may want to implement that windows service in c#, as it is really easy, have a look: Creating a Basic Windows Service in C#.
When using c#, be aware of you have to correctly dispose interop objects, pretty good described in How to properly clean up Excel interop objects
Wanted some opinions on which method is a better practice. We have a sales report that MUST be generated in a very specific format (down to the row colors and fonts).
I already have written a macro which pulls from our database and populates the entire workbook in about 15 seconds. The question is how should it be populated?
1) Process server-side: Users initiate the request on the intranet page. ASP.NET opens the workbook template, executes the macro and serves back the final sheet.
2) Process locally: Users download the blank template, run from their desktops which automatically connect to the database.
I like the first one because I can enforce the template, timing, users, and security of the data. But is running Excel automation on an internet web server recommended? I like the second option, but I'm afraid of losing standardization as template sheets begin floating around the company.
As for server side:
I highly.. HIGHLY.. recommend checking out the OpenOffice/LibreOffice XML format for spread sheets.
You can use the localc binary in headless mode to convert the XML file to XLSX or what have you. I use it to create PDF files instead of using ReportLab.
Alternatively here are some other projects that attempt to write to Microsoft formats directly:
http://pypi.python.org/pypi/xlrd
http://pypi.python.org/pypi/xlwt
As for client side:
If you expect the user to be only using Excel and not any other spreadsheet software then go ahead and use an ODBC data source. ODBC will have to be configured per user unless you use some fun VBScript to pull the data from an HTTP server every time it is loaded. There is also the option of making an XLS spreadsheet that simply holds the data and including it into an XLS document as well which would be both a server and client XLS requirement.
Go for server side. Makes information simple to archive and share and will most likely be multi-platform as well.
If you like to use your first option, then you want to avoid using VBA on an installed instance of Excel on the server. This is extremely resource intensive and does not scale well. Instead, if you are writing ASP.NET code, then you should try using the Microsoft Office Interop functionality that is built into the .NET framework. It should possible to adapt your existing VBA code to run under ASP.NET with some changes, but you will have a much more reliable product in the end.
Example Code
However, as #whardier points out in his response, if this were for a large scale or public site, the suggestions he makes would be much more suitable and would scale much further.
I have read very little content regarding Sharepoint (SP), and most of my reading has been sales pitch oriented overview material. I utilitze VBA with Office apps - especially Access - on a regular basis, and I am wondering if there is any translatable way to retain the custom functionality of writing my own VBA within Sharepoint, especially with MS Access.
I have read that Access databases can be run on SP, with tbales to list and forms to InfoPath, but I am assuming they are primarily talking about Access database apps that were built with wizards, which consist mainly of bound objects without explicitly-defined code.
Most of my app are primarily code driven with VBA because of my automation requirements, which I rely on to perform my tasks. Am I going to be able to accomplish the same thing within SP, and could anyone please provide any references on the subject, specifically?
You can use Access to distribute your front end to users, regardless of how much VBA it has, but an app with VBA code in it will not convert to run in the browser as a Web Database within Sharepoint 2010's Access Services. For that to work, you have to use the new, more powerful macros and limit yourself to the features supported by web objects. For an existing app, this means rebuilding every object from scratch.
Do you need to run your Access app in a web browser? If not, then you're barking up the wrong tree here.
AFAIK Sharepoint does not support VBA.
If you publish an Access database to SharePoint as a web database it cannot use VBA, however you can create a hybrid with the tables in SharePoint and the frontend in Access, that way you can have as much VBA etc as you want and still have the advantages of your data being stored in the SharePoint SQL server. You can store the frontend on SharePoint and have users download it through SharePoint .
The alternative is to keep a traditional Access database on the SharePoint share and access it via webDAV rather than the SharePoint web interface. You could map the SharePoint library as a local drive to make it easy.
Note that drive mapping is considered a legacy technology and will no longer be supported by Windows 11 due to the demise of IE11.
I'm trying to implement an Excel Services reporting solution in SharePoint (MOSS). Since the source data is a SharePoint list, this problem is doubly frustrating. I keep bumping up against permissions problems, even though I've enabled virtually everything in sight.
The first error is about refreshing external data - it's not (really) external data, but that's a semantic point.
The second error is a cryptic "Excel Web Access" problem.
Anyone get this to work??
Could be a couple different problems. The first possibility is that Excel Services doesn't support using SharePoint list data (crazy I know)... although this only applies if you try using the type of embedded data source you get if you choose Export to Excel from a list (again, I know crazy).
However an easy way around this problem is to use the SP webservices to get you list data. I had a macro written by someone at MS a while back that automated this conversion, if I canfind a link I'll post it. If you are using Kerberos then you task is probably finished. If using NTLM then you may need to also configure an SSO application so that the right credentials can be passed to the webservice (or any other data source for that matter). There's a pretty good step by step here.
One kind of "hack" to get this to work via UDF's (which if trusted, custom code can be deployed and made available via Excel Services) can be found here.