Iron Python script execution error on web page.

[Mark123]

Nice day,every one

    When I copy the template that runs normally  both on the web page and the client  to a new folder path in the library, opening this new copy on the web page will result in an error, but opening the same copy on the            client is normal.

    Cannot change attribute.
    Unable to execute script “setMarking”: Could not add reference to assembly JingSi.SFPlus.ScriptJob,Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d95002c27fab778
 
   at Spotfire.Dxp.Application.Scripting.ScriptService.Execute(ScriptDefinition script, Dictionary`2 scope, InternalLibraryManager internalLibraryManager, NotificationService notificationService)
   at Spotfire.Dxp.Application.Scripting.ScriptManager.<>c__DisplayClass8_0.<ExecuteScript>b__0()
   at Spotfire.Dxp.Framework.Commands.CommandHistory.Transaction(Executor executor, Boolean visible, Boolean sticky, Guid stickyGuid, Boolean isHighlight)
   at Spotfire.Dxp.Framework.Commands.CommandHistory.Transaction(String displayName, Executor executor)
   at Spotfire.Dxp.Application.Scripting.ManagedScript.Execute(Dictionary`2 environment)
   at Spotfire.Dxp.Application.Scripting.PropertyChangedScriptEventHandler.<>c__DisplayClass8_0.<DeclareInternalEventHandlers>b__0()
   at Spotfire.Dxp.Application.Scripting.PropertyChangedScriptEventHandler.<>c__DisplayClass8_1.<DeclareInternalEventHandlers>b__2()
   at Spotfire.Dxp.Framework.Commands.RollbackAgnosticTransactionCompletingCallback.OnTransactionCompleting()
   at Spotfire.Dxp.Framework.Commands.CommandHistory.CommitOutermostTransaction(Object busyProof, Boolean oldHiding, Boolean sticky, Guid stickyGuid, Boolean isHighlight)
   at Spotfire.Dxp.Framework.Commands.CommandHistory.OutermostTransactionHandle.PerformCommit()
   at Spotfire.Dxp.Framework.Commands.CommandHistory.OutermostTransactionHandle.Dispose(Boolean disposing)
   at Spotfire.Dxp.Framework.Commands.CommandHistory.Transaction(Executor executor, Boolean visible, Boolean sticky, Guid stickyGuid, Boolean isHighlight)
   at Spotfire.Dxp.Framework.Commands.CommandHistory.Transaction(String displayName, Executor executor)
   at Spotfire.Dxp.Application.Visuals.HtmlTextArea.InteractWithControl(String id, Action`1 interaction)

    Welcome any suggetions. 

    

    

[David Boot-Olazabal]

Hi Mark,

That is kind of weird indeed.
What happens, if you are able to run the template from that new folder successfully in the client, save it back to the library and try again from the web client?

And are the privileges on that new folder, similar to what it was on the old folder?

Kind regards,

David

[Mark123]

18 hours ago, David Boot-Olazabal said:

Hi Mark,

That is kind of weird indeed.
What happens, if you are able to run the template from that new folder successfully in the client, save it back to the library and try again from the web client?

And are the privileges on that new folder, similar to what it was on the old folder?

Kind regards,

David

I have tried to save the new template opened by the client back to the library before.But when  opening the template on the web page, I still get the same error message.

The privileges for the new and old folders can only be confirmed tomorrow. I don't remember making any special configurations for privileges.In addition,I have been using an administrator account.

[David Boot-Olazabal]

Hi Mark,

What does the setMarking script do?
Could you post it here?

Also, as an Administrator, specially in the newer versions, I had to add the admin group to the Script Author (and Custom Query Author) group to be able to run scripts properly as the admin. That may also have to be done on your side. Or try to work with an analyst account that is a member of the Script Author group, open/save the analysis file and try once more in the web.

Kind regards,

David

Edited July 30 by David Boot-Olazabal

[Mark123]

The script is used to import data.And the developer is no longer reachable.

import clr
clr.AddReference('JingSi.SFPlus.ScriptJob,Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d95002c27fab778')
from JingSi.SFPlus.ScriptJob import *
jobManager=ScriptJobManager(Application)
jobManager.RunJob("setColumnName")

 

I'll try to add the Administrator account to the Script Author group.But I don't think it's useful,because the original template runs normally.

[Mark123]

The privileges for the new and old folders are the same.

And I've added the Administrator account to the Script Author group.It has no effects.

[David Boot-Olazabal]

Hi Mark,

The script uses the JingSi.SFPlus.ScriptJob assembly.
Can you tell me where that one comes from? I have tried to copy/paste the script but it fails on that assembly. So I assume one has to install it somewhere. If that is the case, is it installed (or called upon) from specific places/folders? Or should it be generally available?

Would it be possible to share the dxp file, so we can test it out on our side?

Kind regards,

David

[Mark123]

There are indeed plugin packages for both web and client-side, which need to be placed in the Modules directory of all services.For example:<NM install directory>\services\WebWorker-39.4.15705.3754-...-7e5464c641a9 \Modules
I will confirm if it is possible to share the plugin package.

[David Boot-Olazabal]

Hi Mark,

Right, so that explains why the Analyst client doesn't have a problem, since the analyst client modules are used by all sessions.

For the node managers, can you check if there are:
- previous versions that you could delete?
- node manager modules without this plugin package? 

What you can further do to check, to narrow down this problem, is to see if the original template runs always on the same node/instance. If that is the case, you know that this node/instance has the plugin. You can then check the same for the copy template. If that runs on a different node/instance, that might indicate that this node/instance doesn't have the plugin. You can check that in the modules folder, but you can also create a routing rule (in scheduling & routing) to ensure it uses the same node/instance as the original. That way you have also verified that the copy is working and using the plugin.

Kind regards,

David  

[Mark123]

This aspect has been tested.

Two nodes are equipped with plugin packages.And there's no previous versions.

The copied template uses the same resource pool in the routing as the original template.

[Niko Maresco]

hi Mark,

i understand from your messages that the script is running in another analysis on the same Web Player, which is certainly weird. but one of these tests might shed some light on why this is happening.

the error is complaining that the assembly is not found for some reason:

Could not add reference to assembly JingSi.SFPlus.ScriptJob,Version=1.0.0.0, Culture=neutral, PublicKeyToken=4d95002c27fab778

JingSi.SFPlus.ScriptJob refers to a .DLL somewhere on the system. can you verify that the DLL is present and correctly registered? i noticed you mentioned that it is installed to the Node Manager's Modules directory. have you verified that the package containing this DLL was successfully deployed, and that the Web Player service is not pending any update to complete deployment?

another item to check is that the Node Manager machine has a compatible .NET framework version installed. it's not possible for me to say what version that is, but if you are the developer of the JangSi package it should be easy enough to confirm. you could also compare the installed .NET frameworks on a machine where your script runs to the .NET frameworks on the Node Manager.

another test would be to try to add the reference only by its DLL filename (e.g., clr.AddReference("JingSi.DLL") ) or to its explicit path (e.g., clr.AddReference("C:\Windows\System32\JingSi.DLL") ).

this seems like an issue with the .NET environment on the Node Manager machines rather than an issue with Spotfire. you could verify this by running Python's IDLE on the machine and attempting to import the DLL there (or simply making a .py script and executing that).

[Mark123]

I just copied the original template to a separate directory.The original template and its copy are configured to use the same resource pool in the routing. The plugin package has already been placed in the Modules path on this NM, and the old template has been running normally.

So the plugin package has been deployed and there are no compatibility issues about .NET framework.

The deployment steps for plugins on the web page are very simple. Just copy the plugin folder to the corresponding directory on the node manager server (if there are multiple services, the modules under each service need to add script packages), and then restart the service.

[David Boot-Olazabal]

Hi Mark,

As it seems to me, that everything should be working, there are a few things you can try, before opening a ticket with support:
- can you create a new copy of the original template and store it in the same folder as the original? And then open it to see if it returns the same error or not.
- if it works, can you move it to the same folder as the one you currently have your copy and try to run it?
- if it doesn't work, what is the error?
- can you also try to move the current copy to the same folder as the original and try it out?
- and finally, can you move the current copy to a different folder (not being the one where the original is) and try it out.

Also, how do you create a copy? Do you open the original and save it under a different name? Or do you create a copy via the Library Administration Tool? If you have done it always via one way, you may also try the other one.

Kind regards,

David

[barchiel33]

I'm willing to bet the issue is the public key token. I suspect that when the script runs on the original, it adds the reference is essentially duplicating the original script dll into a folder either in your computer or in the Spotfire files. Then when you move your report, it tries to repeat that process but it can't make a new copy since the public key token is specified, causing it to error out. Have you tried having someone who has never opened the original template open the copy in its new folder and run the script?

Alternatively, if you have the file for the reference you're trying to add, you could add the folder it's contained in to your sys path and then add the dll by file name. If the script runs after doing this, then that would be clear proof to me that it is what I suspected. This would only work as a debug test, since other users wouldn't be able to access the dll file location (unless it's on a network drive or something). But it would help determine the exact cause.

import sys
import clr

sys.path.append('C:\PathToDllFolder')
clr.AddReference('MyDll.dll')

 

Edited August 1 by barchiel33
Added new info

[Mark123]

I appreciate both of you. And I will test it as soon as possible afterwards.