Scripted upload vs. Applet Upload

[dickiedyce]

I would like to use a scripted upload. I store the base url in a global field (ui::SCBaseURL), and can use this in a webviewer to upload and view files via supercontainer as expected.

The calculation is:

ui::SCBaseURL & "/Completions/SO/" & Substitute( order::id; "/" ; "-" ) &"/scan"

and this works as expected. I then change the webviewer to this:

ui::SCBaseURL & "/Completions/SO/" & Substitute( order::id; "/" ; "-" ) &"/scan?style=noupload

"

so that I don't get the upload button. Great. All works as advertised.

I then attach a button to the layout with a script which effectively start with the following variable assignment and test:

Set Variable [$result; Value:SCSetBaseUrl( ui::SCBaseURL )]

if [ $result - "ERROR"]

  ...

I get permanent errors at this point and SCLastError gives me a "java.lang.NullPointerException" error. I'm using v2.832 of the companion plugin, and 2.82 of the SuperContainer server (since I can't restart the server at present). Is it just down to the server version mismatch, or am I missing something else?

Any suggestions welcomed.

[ooparah]

Hey Richard,

I get permanent errors at this point and SCLastError gives me a "java.lang.NullPointerException" error.

Not quite sure why this is happening. It -possibly- could be due to a bug related to using the companion plugin functions in IWP/server-side solutions. A bug that has been resolved in our latest build of SuperContainer, which as of right now, hasn't been released yet.

 Set Variable [$result; Value:SCSetBaseUrl( ui::SCBaseURL)]

if [ $result - "ERROR"]

  ...

I am not sure how beneficial this If statement is (or perhaps you have written it here wrong) but, "If [ $result = "ERROR" ]" should yield better results.

I'm using v2.832 of the companion plugin, and 2.82 of the SuperContainer server (since I can't restart the server at present). Is it just down to the server version mismatch, or am I missing something else?

Any suggestions welcomed.

I would definitely recommend upgrading your SuperContainer Server to the latest version as soon as possible. The latest version resolves several issues, which could resolve the issues you are facing. So, step one in this case is to upgrade your server as soon as you get a chance.

Regards,

[dickiedyce]

Yes, sorry... typo re '-' vs. '=' ;-)

Now running 2.832 on the server as well as the plugin. Same issue.

[dickiedyce]

Okay, further to this - I have used the calculation from the *working* webviewer to figure out a valid URL (http://myseveraddr/SuperContainer/Files/Completions/SO/3ef2ff1a-58ad-4b2c-b39c-8144b7968b99/scan), and I've passed it to both

SCSetBaseURL( "http://myseveraddr/SuperContainer/Files" )

and

SCGetInfo( "http://myseveraddr/SuperContainer/Files/Completions/SO/3ef2ff1a-58ad-4b2c-b39c-8144b7968b99/scan")

from which I get ERRORs as well.

[ooparah]

Hey Richard,

This issue may be related to some server-side related issues that were reported when users were calling SCSetBaseURL within a server-side solution. We have been working diligently to try to resolve this issue, among several others, in regards to SuperContainer. Recently, as of 2:50pm ET today, we released a newer version of SuperContainer (2.85) that should resolve your issue. I suggest downloading the latest release at your earliest convenience in hopes of getting your solution working as needed.

 SCGetInfo("http://myserveraddr/SuperContainer/Files/Completions/SO/3ef2ff1a-58ad-4b2c-b39c-8144b7968b99/scan" ) 

However, I should note that most SuperContainer Companion plugin functions request the "folder path" as one of its argument. Here you are passing a complete URL. A well-formed folderPath and call to SCGetInfo() would look similar to:

Note the exclusion of the baseURL --> "http://myserveraddr/...ontainer/Files/"

Let me know if the update resolves your issue,

SCGetInfo( "/Completions/SO/" & ScanTable::Scan ID & "/scan" )