I have a BPMN for document management in KTA. The steps are the following :
Create a TIFF file (scan)
Classify document
Convert to PDF
...
Electronic signature with chambersign
etc.
My issue is the following :
I was asked to develop a Java module in order to get the documents that are processed, to make electronic signature and to send it back to KTA. I just don't know how KTA can call my JAR file.
I would create a .NET wrapper DLL and then call said library in a .NET Activity. Simply calling a JAR from .NET and getting data back is described here, but it might get more complicated that that (since you mentioned sending the document back to KTA).
A possible solution would be to have your JAR simply sign a document that's located on the disk (e.g. c:\in\123.pdf). The .NET wrapper would then download the PDF from KTA's repository, call your JAR, and then upload the updated file again. You can use the GetDocument method from CaptureDocumentService to retrieve a file, here's some code to get you started.
Related
How to do Text file changes in a ZIP file in InstallShield Basic MSI project. I am not able to do Text file changes in a file which is inside a zipped file.
InstallShield does not offer this capability, at least not now. You will have to either surround the call to the text-file-changing custom action with ones that extract and replace the zipped file (the text file changes would operate on the temporary copy), or implement the whole thing yourself in one step. I'm not sure which approach will be easier.
In your situation, I would reframe the design and requirement. Silverlight .XAP files are typically digitally signed. Any attempt to modify the archive would invalidate this. It's also needlessly complicated.
Instead, change your application to use an external configuration file. native InstallShield functionality can then be used to update this file. For a possible approach, see:
Creating and Using Silverlight web.config app settings (Web.config Configuration Applicatioin Settings) or app.config application settings configuration file for Silverlight
I'm working on a C++ Windows Store DirectX app and I'm trying to save screenshots to disk every so often.
I am using the DirectX Tool Kit (DirectXTK) and the function SaveDDSTextureToFile which returns an HRESULT.
The problem is that the returned HRESULT is always:
E_ACCESSDENIED General access denied error.
I assume this is some permissions/capabilities thing (it being a windows store app) but I can't find what I need to ask for permission for to be able to save files to disk.
The DirectX ToolKit says it is for Windows store applications as well as desktop applications but I can't find any information on their codeplex either.
Does anyone know what I need to have permission to do for this to work?
Thanks for your time.
Windows Store apps are sandboxed and have fewer permissions than desktop apps, especially when it comes to file access. By default, apps only have access to write to the local storage directory, which isn't easily accessible from the shell. If you want to save to the Pictures or Documents library, you will need to specify this access in the package manifest. Additionally, you will need to use the WinRT file APIs to write the DDS files. To do this, use SaveDDSTextureToMemory, then write the resulting raw DDS data to the StorageFile. Check out the File access sample for more info on the WinRT APIs involved in writing this data as a file.
I've managed to find a way to do it. Basically as MooseBoys says you cannot save to anywhere because the app is sandboxed.
You can however save to the TempState folder of your apps package in AppData, which is all I need because I'm using this feature for debugging.
So the line I call is:
DirectX::SaveWICTextureToFile(deviceContext, texture2D, GUID_ContainerFormatPng, L"C:\\Users\\USERNAME\\AppData\\Local\\Packages\\PACKAGENAME\\TempState\\test.png");
And this works great.
I have loaded a custom jar file into WSO2 by placing it into the /repository/components/lib directory, performing a restart. I then call that class from a script mediator using inline groovy. The groovy script recognizes the class, however the custom class is attempting to load a properties file that must be on the classpath. I have put that property file nearly everywhere but I keep getting an error that it cannot find the file on the classpath.
I am running the standalone WSO2 ESB 4.7.0. I have put the file as part of the jar, I have also attempted to place it in several directories within the WSO2 file structure as well. All to to avail.
you could try to register a resource in the carbon registry and add a Property to this Resource. Basically there are two ways (in java...):
Here is an example how to connect to the registry via a service with the PropertiesAdminServiceStub: http://www.massapi.com/class/org/wso2/carbon/registry/properties/stub/PropertiesAdminServiceStub.java.html
The most important here is that you authenticated your user, the result is a cookie which yoou have to add to the stub.
The other would be something like this (probably a duplicate of your question)
I am unable to get the list of services with in the applicaton i.e.; wso2 governance registry? I am working with binary code
The last one asumes that the carbon-context is available, means you are running the search inside the wso2 like a feature for example.
Unfortunately there is no place to put that properties file. Luckily this jar file, is an in house entity. It was written to search the classpath for the properties file and upon not finding one on the classpath to throw an exception. We ended up rewriting the code that loads the properties file to upon not finding the file on the classpath to search in a directory which we specified as a system environment variable in the wso2server.sh file. Not very elegant, but it is working perfectly.
When I try to generate a javadoc, using the menu command Project\Generate Javadoc, the following warnings and error are produced for my custom classes in XPages:
javadoc: warning - No source files for package net.focul.utilties
javadoc: warning - No source files for package net.focul.workflow
javadoc: error - No public or protected classes found to document.
The packages are in the WebContent/WEB-INF/src folder which is configured in the build path and are selectable in the Generate Javadoc wizard. The classes are public with public methods.
Javadocs are generated for all of the Xpage and Custom Control classes if I select these.
You're experiencing this behavior because javadoc doesn't understand the Designer VFS (Virtual File System). It assumes that your project consists of a bunch of separate files in some folder structure on your local hard drive, not self-contained inside a single NSF. On the whole, the Designer VFS successfully tricks Eclipse into believing it's interacting with local files by intercepting read/write requests for project resources and importing/exporting DXL or CD records, etc. But apparently they haven't applied this sleight of hand to javadoc as well.
The Java source files corresponding to each XPage and Custom Control are processed successfully because, ironically, they are never stored in the NSF. During every project build, Designer discards any of these it has already generated and re-creates them based on the current contents of the various .xsp files. It then compiles those Java files into .class files, which are stored as design notes inside the NSF. At runtime, it's these files that are extracted from the VFS and executed... the source code no longer matters at this point, so there's no reason to ever bother including the .java files in the NSF, so they're just kept on the hard drive. One indication of this behavior is that the folder is named "Local" when viewed in Package Explorer / Navigator.
If you're using the built in (as of 8.5.3) version control integration (see this article for a great explanation of how to use this feature), you can tweak the Build Path to include the copy of the src folder stored in the on-disk project as a "linked source folder". This causes javadoc to consider the duplicate copies valid source files, and therefore includes them in the generated documentation. On the downside, it also causes Designer to consider them valid source files, which causes compilation errors due to the duplication. So this approach is only viable if you only need to generate the documentation on an infrequent basis, and can therefore break the Build Path temporarily just to run javadoc, then revert to the usual settings.
An alternative is to actually maintain your custom Java code this way on an ongoing basis: instead of creating the folder in WEB-INF inside the NSF, just create a folder on your hard drive that stores the source, then include that location as a linked source folder indefinitely. That way Designer can still find the source, but so can javadoc. NOTE: if you go this route, then you definitely need to use SCM. Because your source code no longer lives inside the NSF, providing the convenient container we're used to for getting the source code to other developers and ensuring inclusion in whatever backup schedule you use, the only place your source code now lives is on your local hard drive. So make sure you're regularly committing those files to Git / Subversion / Mercurial, etc., or, at the very least, storing them on some file server that is backed up regularly and, if applicable, accessible to all other members of the project team.
When you expand the net.focul.utilties in Designer, you will see all the methods and properties. But when you click on on of the methods, you will see neo source code.
So this is where javadoc fails to generate the documentation. I guess that the author of the application has not provided you with the source code. If you have the source somewhere, you can attach this code and then javadoc will be able to generate the documentation.
I run into the same situation and I have found the most straightforward method is to export the source to an external folder and then use regular Eclipse to generate the JavaDoc. Not sure my process is any less of a hassle than Tim's suggestions but for me it just feels less risky than trying to deal with the VFS vagaries.
I have a need to convert any document gets uploaded to Image.
I downloaded the exe (with all the dlls) on my local machine (dont have to install)
export.exe sourcefile.doc destinationfile.gif >> this syntax works from my local dos prompt.
How do I use the same syntax "export.exe exampledoc.doc exampledoc.gif" when an item is added to sharepoint doc library.
and Do I need to put the folder (where the exe and dlls are for this) in the sharepoint frontend server so it's accessible? If yes, where should this folder reside? Does the folder and files need sharepoint service account access?
I am totally new and I would really like if someone can shed some light on this (step by step if possible)?
Thanks
Justin...
In order to do this from a SharePoint event handler, each WFE on the farm would need to have your conversion application available, your event handler code would need to place the uploaded file in a temporary location on disc, invoke the conversion application (look at the .NET Process class for this), cancel the addition of the original, unconverted document, and add the output of your processed file to the library (ensure you use the DisableEventFiring() method of the event handler as to not have the event handler trigger itself during the addition of the new file), and then clean up after itself.
Having said that, this operation seems like something that you really wouldn't want to tax a web server getting any real traffic with doing in real time. You may want to look into batching the jobs to be done daily during traffic lulls by another system, or one dedicated resource on the farm.