4 Replies Latest reply on May 5, 2011 10:44 AM by John Messinger

    Concurrency in AFAnalysis

    John Messinger

      Hello all,

       

      We are developing an AF Analysis rule based application that will be used to produce data files for importing into a reservoir modelling application. The reservoir engineers will have access to the analysis rule through a web front end, which in turn will use a web service to pass configuration parameters to the analysis rule on the AF server, and then execute the rule.

       

      In our test environment, the rule, web front end and web service all work quite well together. But one issue that we are concerned about is concurrency, when more than one user wishes to run the rule to produce an export file at the same time. The middle tier web service passes parameters to the analysis rule by writing a new ConfigString to the rule each time a user configures the front end with the required parameters for a data export (gas field, starting date, end date, reporting basis - daily, monthly, yearly).

       

      My question is this - how does AF handle concurrency in this type of scenario (if at all), and if it doesn't handle it natively, what type of approach would the community recommend to handle this. I have had some ideas about this, such as multiple threads on the web service, each one sandboxing the config string (not checking it in) and then running the rule, but I haven't as yet tried this out. I'm keen to hear others' ideas on approaching this problem.

       

      All components (web front end, web service and analysis rule) are coded in C#. We are also using AF 2010 R2.

       

      Regards,

       

      John

        • Re: Concurrency in AFAnalysis

          Hi John,

           

          Are you making use of the AF Models/Cases (i.e. is your Analysis Rule scheduled) or are you simply using the Analysis Rule as the mechanism to execute your logic for creating the data file?  If you have multiple users are you looking to persist the string back to AF; depends on your answer to the first question I guess.

           

          Just trying to understand how often you are running the analysis and the choice of using an AR.  I haven't answered your question just yet.

            • Re: Concurrency in AFAnalysis
              John Messinger

              Hi Rhys,

               

              We are making use of AFModels/AFCases, but the Analysis Rule isn't being scheduled - it's intended to only be run on demand (ie, using the Analysis Rule to execute the logic for creating the output file).

               

              The engineers would probably use the tool only a few times during the month (or even only on a quarterly basis), but given there are 6 or 7 of them all requiring slightly different output files. At present we are persisting the config string back to AF, but this is where our issue comes into play - is this necessarily the best thing to be doing? We don't need to do this, as each run of the analysis is more than likely going to be under a different configuration (gas field selection, date range etc). I'm pretty sure that persisting the string back to AF will likely lead to problems for us should more than one user run an analysis at the same time, each with a differing configuration.

                • Re: Concurrency in AFAnalysis
                  cmanhard

                  Are you requiring the cases to be stored?  If not, then consider just creating an analysis “on the fly”, running a “temporary case”, then removing the analysis (analysis.UndoCheckOut) when complete (after publish).

                   

                  If you do require the case runs to be stored, then I suggest an alternative to modifying the configuration string would be to have your analysis rule read the particular configuration it needs from somewhere other than the analysis rule configuration string.  For example, an attribute attached to either the case or the target.  For an attribute attached to the case, you could simply set the value.  For an attribute attached to the target, use AFCase.AddInput(attribute, value);  The advantage of the either of these is that the specific configuration would be saved with the case.