Jiwa

This was an issue on V 7.0 and I would like the programmers opinion on V 7.2. (This occurrence is very hard to replicate but has happened randomly on v 7.0) .
I am doing a similar project on V 7.2

I would like to know if the behavior still exists in Jiwa 7.2 and preferably any legal workarounds for that.

Description:
Jiwa file watcher is fired by plugins ( csv or xml). However, this uses a licence to login.

( eg: for sales order imports ) ; The issue is even if Jiwa does not find a free licence to login , especially when there are multiple similar plugins running, it will still extract the file from the watch folder and dump it into succeed folder without actually processing it.

Eg: If a sales orders is being imported then the order will not import but the file ends up in the succeeded folder.

This means a legitimate file is discarded.

Hi Indika

You can get around the problem by creating a user and attaching the the license specifically to that user in the licensing screen, that way there is never a chance that the login will fail as a license is kept in reserve for your specific user and they can always login.

indikad wrote:The issue is even if Jiwa does not find a free licence to login , especially when there are multiple similar plugins running, it will still extract the file from the watch folder and dump it into succeed folder without actually processing it.

Eg: If a sales orders is being imported then the order will not import but the file ends up in the succeeded folder.

This means a legitimate file is discarded.

Hi Indika,

I cannot see how this is possible, unless you've got in your config for the Jiwa Plugin Scheduler Service the same database on the same server twice, or you're running multiple instances of the Jiwa Plugin Scheduler Service.

The Jiwa Plugin Scheduler Service at the poll interval specified in the JiwaPluginSchedulerService.exe.config file, examine the Databases section of the config:

Code: Select all

<Databases>
   <Database>
      <DatabaseName>JiwaDemo</DatabaseName>
      <ServerName>localhost</ServerName>
      <JiwaUsername>Admin</JiwaUsername>
      <JiwaPassword>password</JiwaPassword>
    </Database>
</Databases>

And for each database in that config, it will Logon once and then invoke the plugins implementing the IJiwaScheduledExecutionPlugin interface. It does not logon for each plugin and thus it will only use once licence for all plugins.

If your file watcher is moving files to the succeeded folder and not actually processing the file, then something else is going on - for it to even be able to move the file, that means your file watcher plugin is running - and that only occurs after a successful logon the Jiwa Plugin Scheduler Service makes for you.

As Stuart mentioned you may be able to side step the whole issue by explicitly attaching a licence to the user the Jiwa Plugin Scheduler Service is configured to use - but I really don't think your issue is a licence issue.

If you look at the code in the file watcher plugin (If you're using the sample File Watcher plugin we ship with?), you'll see the conditions around moving a file to the succeeded folder - it should be fairly easy to work out why this is occurring for you and seemingly not processing.

Mike

I have a specific user. However that is used by multiple file watcher plugins, with multiple instances of the plugin scheduler service running. My suspicion is the failure occurs when two or more plugins try to login at the same time ( not 100% as this happens randomly).
I have made sure the file (csv) data is ok. (if I re-fed the file to the watch folder it did import.)

If you are saying that all plugins use the same login even when two or more plugins run at the same time , then I may need to look at other areas. I have used the sample file watcher plugin and the only significant add-on to that is an explicit database connection I create ( ADO .Net ) for reading tables and one one occasion to insert a record to an external table.
That insert method too is set to ignore errors and continue (however that bit occurs after the sales order save occurs ) , so I am not sure how it could cause a conflict.

indikad wrote:If you are saying that all plugins use the same login even when two or more plugins run at the same time

That is true, but now that I think more about it the File Watcher plugin is a special case and you may have issues with licencing after all - or something else.

The File Watcher plugin only services the OnServiceStart method of the plugin - not the Execute method like all other plugins - so when the ServiceStarts it adds a hook into the file system to be notified of file events in the Watch folder - So it is actually from then onwards functioning outside of the Jiwa Plugin Scheduler Services control - so the logon phase of the Jiwa Plugin Scheduler Service has no impact on the File Watcher.

If you look at around line 805 of the File Watcher plugin you'll see this code:

Code: Select all

' Raise the event so the work is done
RaiseEvent FileImport(pendingFileNameAndPath)
         
' Move to succeeded folderPath.Combine(Me.PendingFolder, System.IO.Path.GetFileName(FullPath)
Dim succeededFileNameAndPath As String = Path.Combine(Me.SucceededFolder, System.IO.Path.GetFileName(FullPath))

If System.IO.File.Exists(succeededFileNameAndPath) Then                             
   succeededFileNameAndPath = Path.Combine(Me.SucceededFolder, System.IO.Path.GetFileNameWithoutExtension(FullPath) & "." & now.ToString("yyyy-MM-ddTHmmss.FFF") & System.IO.Path.GetExtension(FullPath))
End If

The first line of code is what I think is the issue - the RaiseEvent FileImport is no longer being listened to, and it continues along merrily and moves the file to the succeeded folder. Now what would cause that to be no longer listened to? the ScheduledExecutionPlugin class which added the handler may have been disposed of for some reason.

Note that there is logging in most of the handlers - for example in the sales order CSV import it concludes with "Imported Sales Order Invoice No. '{0}' With Order No. '{1}' from File '{2}'" - are you seeing anything like that in the event log for these files which are moved to the succeeded folder?

I'd add some more logging to try and hone in on what exactly is occurring in what sequence - and put in some try catch finally blocks around the FileImport handler and log to the event log in the catch and finally.