Metastorm File Migration Assistant.. is it efficient?

Hi Guys,

The file migration assistant as I understand adds a 'Evaluate' wrapper around the existing 7.6 code when doing the migration.

Any thoughts if this code that gets generated is efficient or is it advisible to manually re-wirte the 7.6 code to 9.0?

We have many existing 7.6 maps in production and re-writing them to 9.0 would be a very big effort which may not get business approval. At the same time, if converting using migrator assistant does not give any performance benefits, then it will be difficult to justify why the conversion is required.

Regards,

Hemant

Find more posts tagged with

BPM

Comments

Jerome_Pearce

I would imagine that the same code as was used in version 7 wil be run in version 9 for the Evaluate() function. As such, it is probably not going to make much difference. Performaance within the Engine itself is rarely an issue. Database and network considerations are more important.

The greatest concern is probably the lack of ability to edit this code. In effect, if you need to change anything more complex than single line statements, you will be much better off rewriting that segment. This does, at least, give you the opportunity to manage an incremental upgrade. There are, however, some elements that may not come across correctly and will need replacing in any case. These tend to be grids, especially if you have done anything more than a very simple grid.

Our approach will probably to migrate simple processes, and if a large amont of rewritig is involved and design changes could be of benefit, then rewrite from the bottom up.

Jerome_Pearce

One or two discussions here:
http://metastorm.processmapping.com.au/?forum=157535

http://metastorm.processmapping.com.au/?forum=157519

Hemant Chauhan

Thanks for sharing your thoughts on this Jerome.

We have some complex grids which make use of dynamically generated 'where' & 'order by ' clause. I guess all that will need to be re-written.

I do agree that database and network are major bottlenecks.

So it seems that migrating to 9.0 wont bring any performance improvement to the application as such.

Rob Vignerot

It really depends upon what you mean by performance improvements. I find that people refer to this in a variety of ways. In an n-tier system there are numerous potential bottlenecks to end user performance. V9 improves performance in a variety of ways, but these are not always going to be apparent to every process or system/network architecture. Some of the ways V9 improves performance include:

The use of compiled code in the new expression language and visual scripting vs. interpreted scripting with the older %script() language.
Fewer round-trips between the web client and the browser means that the effects of network latency between the web client and browser are diminished..
Improved use of caching in the web client means that end user performance actually increases with a base load on the system.
Improved use of caching in the engine server means that there are fewer calls to the DB reducing the load on the DB and the effects of network latency between the engine and the DB.

Hemant Chauhan

Hi Rob,

The use of compiled code in the new expression language and visual scripting vs. interpreted scripting with the older %script() language.
When using the migrator tool, if the existing 7.6 code gets wrapped around a %Evaluate(), in that case will it be using the complied code or will it still be interpreted??
Fewer round-trips between the web client and the browser means that the effects of network latency between the web client and browser are diminished..
This is where I can see some improvement when migrating from 7.6 to 9.0.

3. Improved use of caching in the web client means that end user performance actually increases with a base load on the system.
Our security policy forces a user to clear its browser cache when ever the browser is closed. This web client caching feature wont be useful to us i guess

4.Improved use of caching in the engine server means that there are fewer calls to the DB reducing the load on the DB and the effects of network latency between the engine and the DB.
I would like to see this feature. I compared the sql profiler output between 7.6 and 9.0 form. It looks like every time a form is opened, it makes the exact same calls to the db. I could not see fewer calls to the db on subsequent loads. I will attach my findings in the next post.

Rob Vignerot

1. The use of compiled code in the new expression language and visual scripting vs. interpreted scripting with the older %script() language.
When using the migrator tool, if the existing 7.6 code gets wrapped around a %Evaluate(), in that case will it be using the complied code or will it still be interpreted??

No. The %script() code in v9 is still interpreted. I'm just saying any new expressions or visual scripts are compiled.

Fewer round-trips between the web client and the browser means that the effects of network latency between the web client and browser are diminished..
This is where I can see some improvement when migrating from 7.6 to 9.0.
Improved use of caching in the web client means that end user performance actually increases with a base load on the system.
Our security policy forces a user to clear its browser cache when ever the browser is closed. This web client caching feature wont be useful to us i guess
This is browser caching. This is IIS caching.

4.Improved use of caching in the engine server means that there are fewer calls to the DB reducing the load on the DB and the effects of network latency between the engine and the DB.
I would like to see this feature. I compared the sql profiler output between 7.6 and 9.0 form. It looks like every time a form is opened, it makes the exact same calls to the db. I could not see fewer calls to the db on subsequent loads. I will attach my findings in the next post.

Hmmmm - Maybe I had that wrong. I thought that the way we now handled expressionable properties would have reduced the queries. I'll double-check with the team.

Hemant Chauhan

Hi Rob,

Can you point me to the document that gives more details about this IIS caching in 9.0. We do have set the content expiration in the IIS to cache static files. But I guess this new 9.0 caching is different.

I would like to understand it so that I can add it to my list of 9.0 advantages when doing the POC.