This content has been marked as final. Show 11 replies
fPMGetState does not currently work with Phased Submissions turned on. The last time I spoke to Oracle support about this, I was told that there would be an API enhancement for managing Phased Submissions in a future release.
Thanks for your answer, is there any other way to find the state/review level from the location with the current API ?
fPMGetState works fine with Process Management Review Levels, but not Phased Submissions. If you turn off Phased Submissions in HFM, fPMGetState will work. I don't think there is anything in FDM out-of-the-box for managing Phased Submissions. You could create a custom object that uses HFM API calls to manage Phased Submissions, register that object with FDM, and call your new object's functions/procedures from an FDM Event script. Unfortunately, I've never done that myself.1 person found this helpful
Have you tried the HsvProcessFlow Type Library ???
it seems to do something similar
I have not, but this looks like the library that would get it done. The problem that I've always had with incorporating the HFM API into FDM is that you have to instantiate an HFM session object to use any of the useful libraries, which requires an HFM password. I've never been able to figure out how to "hide" a password in the custom object or in the FDM script. I'm sure somebody on this forum has found a way around this???1 person found this helpful
There is never anything like 'perfect security'. If someone wants to get into your system, they will. With that in mind, the best you could do with a user account to get details from HFM is 'reasonable security'. With that in mind, I'd offer the following advice and you could go as far as you want with it. (or not use it at all. :) )
First of all, I'd make an HFM account just for the purpose you are looking at. If you can make it read only, or even limited to a single entity, etc, obviously that is the best case.
Secondly, if you are using Active Directory for authentication, I would change this user so that it does not have the capability to connect remotely. This would limit it's usefulness if it's password were discovered. (i.e. no one externally to the company could authenticate with it and access the system.)
Next, if you're just afraid of a casual user opening a file and seeing strPassword = "Bob", then you could do something like build the string in multiple stops in the script file AND use chr function to obfuscate it:
Line1 - P1 = chr$(66) <--- Password part 1
Line2 - U1 = chr$(66) & chr$(111) & chr$(98) <---- User name, I'd break this up and hide it too, just so you don't clue people on to what you're doing.
Line 10 - P2 = chr$(111) <--- Password part 2
Line 20 - P3 = chr$(98) <--- Password part 3
Line 12 - S = "ServerName" ' <--- I'd break this up too but for brevity I'm not doing that here.
Line 13 - A = "App" <--- I'd break this up too but for brevity I'm not
Line 50 - OpenApplication(U1, P1&P2&P3, S, A)
Most people glancing through the file who do not know what the API call is for, will not even realize that there is a password here. Casual observers would miss it and would not translate ASCII code in their head. Of course, someone could still sit around and figure this out.
If you're still paranoid, I would store the password (and other info as well) in a file/database table in an encrypted format. Then FDM could would pull the value and decrypt the result. This would prevent a casual user from opening the code and finding a plaintext password (or other info). Once again; however, this is not perfect.
The decryption routine will obviously be in the vbscript and someone could just use that code to unencrypt the information in the file/database. Once again though, you've limited the amount of people who could do this. This is a step better though because the password/config information are not actually in the vbscript. If someone 'stole' this code and put it on the internet, the information is still technically safe unless they also get access to the file/database holding the original data.
If you like to wear tin-foil hats, you can take this another step out. Configure it so that the FDM code calls a web service hosted on a private/local server. The web service would then perform the action(s) you want and would just return a result to FDM. This could be done via an AJAX style call (HINT:XMLHttpRequest) from the FDM script. The connection information could then all be hidden in a compiled executable running on a security server entirely separate from the FDM server and it's scripts.
If you want to take that a step farther, configure the web app so that it only allows communications with the FDM server(s) to ensure that no other machines can attempt to talk to the web service. (realtively easy to do via IIS and Apache)
Do you have a code snippet of HFM API being used in FDM by any chance ??
Im using the Workbench and importing the Type Libraries but when I hit run, an error show up saying 506 - Class not defined
I would reeeeeeally appreciate any help now that Im going with a full rookie custom solution
Have you registered the DLL in FDM? From the Workbench File menu, select "Register Adapter" and select the DLLs you want to use.
How do I know it's been properly registered ?? I did what you suggest but I'm still getting the same error
I tought the correct procedure was to add a Type Library, is that also needed ??
Edited by: HFMColUser on 10-ago-2011 12:08
I don't know if there's a way to verify that the library is properly registered, except to include the required objects in your code and test each one, step-by-step. My experience with external objects is pretty limited, so I don't know if the way I've done it in the past is "best practice" or not, and I've never seen Oracle documentation detailing this process, but this is the way I've exposed DLLs to FDM:
1. The DLLs (Client AND Server) that I wish to use are installed driectly on the FDM application server. Configuration and system startup of server components is often not necessary. The server libraries just need to be available on the FDM server.
2. All required DLLs are registered from the File menu in FDM Workbench on the FDM server - do this on the FDM server, not a client machine.
3. In Workbench, under the Object Browser, add the Type Library(ies) that you want to use. Be sure to include any dependent libraries.
4. You should now be able to drag and drop the object properties, methods, etc. into your FDM scripts from the Object Browser.
5. Follow the application's API guide for further details. For instance, the HFM API Guide gives pretty explicit instructions for instantiating objects, object dependencies, method calls, etc..
6. Test each newly coded process, starting with logging on to the target application. Be sure to capture any errors and log them and/or display them to the user. This will help in debugging.
maybe someone can help me: I am trying to use HFM Objects from FDM, but without success.
Folllowing Larrys guidelines, I did:
1. Register HsxClient.dll from Financial Management/Client Folder on FDM App server with FDM workbench client => I receive a message that it was succesful
2. Import HsxClient.dll libraries into FDM => I can see the library
3. Try to open HsxClient object in FDM Script. Here I always get an error saying that the hsxclient class is not defined. I tried following codes: Set test = CreateObject("HSXCLIENTLib.HsxClient") and Set test = new HsxClient
Maybe someone can help me on how to initalise the hfm objects. Do I need a different coding? Or is the registration of the dll not correct (Where could I check this?). One strange thing is also - as soon as I restart the FDM Workbench client - the hsxclient library is not visible anymore.
Many thanks in advance for your input.