In LN6, agent manipulation via API fails :-(

Hi

The following only happens when using LN6, LN5 works fine.

Task:

We use a small dialog to rename a bunch of documents, i.e. in a Project Database to rename a Project Title. The user shall be able to have an agent doing the job, preferably at times no other user has a document in use. The dialog allows to set the time the agent will run.

Code:

The script is based on Rods Source Code, http://www-10.lotus.com/ldd/46dom.nsf/c21908baf7e06eb085256a39006eae9f/65389424caefa06980256b260051da56?OpenDocument

(Thank you for posting this!).

From within the dialog a customised OK Button will call the SetAssistInfo function to set the agents run time (+ stop time). The script then sets the agent to IsEnabled and saves it using Lotus Script.

Problem:

As said, this works fine for LN5. Within LN6 we get a nice msgbox, saying: “Document has been modified or corrupted since signed! (data)”.

Trials:

To avoid this, we set the agent IsEnabled property via API, too. That means we use

NSFItemSetText hNT , “$AssistFlags”, “Es”, 2

to enable + schedule it

NSFNoteSign hNT

to sign the document

NSFNoteContract hNT

to compress data in the note

before we write the document back to disk (NSFNoteUpdate).

That does no longer raise an error - but the agent never will run. If we look at the agent it looks perfectly fine, no obvious errors etc. (In case the agent was disabled before our script ran, it will be enabled now, etc.) If we test the agent it gives back “Unable to run agent; data is corrupt!”.

Once the agent is saved manually it will work as expected (using the settings assigned via the API calls).

Again, the same stuff works in LN5.

We tested quite a lot with slightly different results (once the agent ran but gave the

Question:

Could anybody put some light on this.

Lotus, if this is a new security feature, thank you.

Subject: In LN6, agent manipulation via API fails :frowning:

Can you switch to using LotusScript (or Java)? You can enable/disable agents programatically in LotusScript and this works well for me. In ND6 this can be done both on the server and on the client. I have always read that manipulating agents as documents is not supported/recommended. The danger of working with unsupported functionality is that the internals can change.

Subject: RE: In LN6, agent manipulation via API fails :frowning:

Hi

The first version of the script enabled the agent via Lotus Script (since this was the easiest way doing this), which gave back the error as msgbox.

We now even tried to enable those agents via an additional Notes Script based agent which runs after the changes via API - but those agents have to be enabled via the GUI, else they will be treated as corrupted.

Regards

Subject: RE: In LN6, agent manipulation via API fails :frowning:

I’ve been running into this problem since R6 betas. I was re-compiling an agent programmatically – since R6 I get the same message about corrupt data though a simple manual clicking on “Sign” in agent view fixes this problem.

I have found no workaround. As you noticed even the use of the new LotusScript Sign method does not sign these agents properly.

Subject: I ended up using the following code in my sign class…

idStr = Hex$(aDesignElements(i))Set doc = db.GetDocumentByID(IdStr)

If Not (doc Is Nothing) Then

rc = NSFNoteGetInfo(doc.handle, NOTE_CLASS, NoteClass)

flags = doc.GetItemValue("$Flags")(0)

T1 = InterpretClassAndFlags(NoteClass, Flags)

If T1 = "AGENT" Then

	title = doc.GetItemValue("$Title")(0)

	Set doc = Nothing

	If s.CurrentAgent.Name <> title Then

		Dim a1 As NotesAgent

		Set a1 = db.GetAgent(title)

		Call a1.Save

	End If

Else

	Call doc.ReplaceItemValue("qwertyqwertyqwertyqwerty", "qwerty")

	Call doc.Save(True, True)

	Call doc.RemoveItem("qwertyqwertyqwertyqwerty")

	Call doc.Sign  'Just a sign by itself w/ a save does not set a dirty flag so the save will not happen 

	Call doc.Save(True, True)

End If

End If

Subject: RE: I ended up using the following code in my sign class…

I think I’ve seen you mentioning this solution in BP Tech, and that’s similar to what I had for R5. However in R6 I can’t make it work in no combination. Either using doc.sign or notesdatabase.sign, nor by signing doc itself or as an agent.

Maybe my problem is that I’m compiling the code…

Subject: I forgot that we did talk about that.

Subject: Solution?

Did you find a solution to this problem? I am getting this same error.

Subject: Solution? 6.0.1

Subject: Some Updates …

Hi

Just some updates on this post …

The following only happens when using LN6, LN5 works fine. <<

No, LN5 did not work fine.

Lotus, if this is a new security feature, thank you <<

Apologise for that, it is a security feature and this behaviour is correct …

I thought about the original aim of the program and found the entire approach to be wrong. To briefly summarise what I wanted:

  • Give any user the ability to schedule an agent on demand. The agent shall run as a scheduled agent on the server. It shall run only once after being enabled.

This approach has to fail first because not every user has Manager access to the database - and therefore is not allowed to enable/manipulate agents.

This approach has to fail second because not every user has the right to run any agent on the server. Once a user has enabled the agent it is signed with the users signature and therefore will not run on the server anymore (given the user is not part of the Admin group etc.).

Of course that happens for LN5 as well.

Therefore the entire approach to tweak the agent did not support the entire aim of the solution.

A working solution is to set up an agent which runs continously (every 5 min.) and checks if to perform further actions or not. This check does not consume resources (<1 sec.), so running this agent continously should be OK. This check is done by reading a Setup document which tells when to run and when to stop. This Setup document is created by the user as well as any other configuration document which details the actions to perform.

Therefore any user can configure the runtime of the agent regardless of his/her access rights (in this database, only Managers can see the option to schedule the agent but criteria could be a role, too, etc.).

Regards