Jump to content

Executing SQL Statements within JavaScript


swartzks

Recommended Posts

There is no mechanism in FusionPro to write back to an ODBC data source at composition time. The database is "read-only" to FusionPro.

 

If you can be more specific about what you're trying to accomplish, I might be able to either suggest an alternate approach or formulate an enhancement request to add to our roadmap.

Link to comment
Share on other sites

  • 1 year later...
Hey Guys... see this thread is a year old... but if monitored here goes, otherwise I'll repost as new.. I'm getting in records daily that I am going to process. I'm loading them into a ODBC connected database, that I will run FusionPro Desktop from. I'd really like FusionPro to update a field every time a record is processed. Say with a "processed batch number". That way I know the record was "fulfilled". Any thoughts on how to accomplish this would be appreciated... since FusionPro is opening ODBC read only.... I could write an app to kick off (I think there is a hook in Fusion to kick off an app at the end of processing???) and mark the data as processed... but that is indeed much messier, and "assumes" that fusionPro processed the image and the entire run "just fine".... Thoughts????? Thanks! Bill
Link to comment
Share on other sites

Even if there were a hook in FusionPro to be able to write back to the database, I'm not sure how you could know whether a record is (or is going to be) properly "fulfilled" at composition time, since everything happening in FusionPro is basically a prepress operation. Wouldn't you have to determine that farther down in the workflow, say, after the piece was at least printed? It seems to me that this falls under a larger category of JDF-type workflow tracking. Maybe you can emit a barcode that can be scanned in some post-press step to update the database?
Link to comment
Share on other sites

Hi! Thanks for the reply. I do my own total job tracking (almost exactly as you mentioned), but here's where fusion pro really does fall short...

 

Have 1 database to create some (lets say... welcome notices). I'm pumping in file records over the course of the day. I'd like to kick off FusionPro Desktop a few times a day to create images. Images that I have an server app automatically see the file and print it. Since fusion pro does not allow any fields in the record to be marked as it processes them, it is a sheer gamble if I run an app right after fusionpro runs and I mark all the current records as "processed" which I would have to do to not have those records show up again the next time FP is kicked off. I also have to ensure no other processes attempt to add records during any time as fusion pro starts running, until after a "kicked off app" to mark the records taken runs because a record could get added and marked processed (exten though it was not) if my external add application was "campped on" attempting to open the database shared right after FP stopped running, and before my exit app runs...

 

Anyway, sure I know that I'll catch at the end of the day, but a lot of work and worry. Again, its a shame that FP does not allow a full control of an ODBC table, able to change an existing field, or even say add a record to another table. Wouldn't that be very handy indeed.

 

Thanks for listening. Bill

Link to comment
Share on other sites

FusionPro Desktop is the wrong tool for this job. You should consider using FusionPro Server.

 

The problem is that you're trying to use FusionPro Desktop in an automated batch composition environment, something it's not designed to do. It is, however, exactly what FusionPro Server was designed for.

 

FusionPro is a variable data composition engine. It's not a database or business logic management system; it was never intended to be, and it never will be (especially at $799).

 

Theoretically, there are all kinds of sophisticated data processing functions that could be added to FP Desktop, but that's not what it's meant to do, and frankly, adding hooks to write back to a database from JavaScript would not provide the performance necessary for an enterprise-level application.

 

Now, FusionPro Server is a different story. It's still just a tool (though a very powerful one) for variable data composition, but it's intended to be a component of a custom application, one which you can write to manage your data and fulfills orders based on your own business logic. Any logic that you would program in a JavaScript rule inside of FusionPro Desktop to write back to a database is better handled in a custom application written in a language (such as C# or Java) that's designed to work with databases.

 

Actually, you mention that you already have a "server app" that handles most of the business logic, so that's where you want to add any other logic to update the database. Your app should automatically compose batches of records via FusionPro Server instead of manually running compositions in FP Desktop. (You can use DL Queue for this, or your own code.) What I would do is have your app mark the records in each FP Server batch request as "in progress." Then your app can capture the return code from the FusionPro Server process in order to know whether the records any given composition were processed successfully, and then update the database appropriately. This will eliminate much of the guesswork and "sheer gamble" that you have now with trying to use FP Desktop in an automated solution. You'll also gain some huge advantages in speed and scalability.

Link to comment
Share on other sites

Hi Dan. Thanks for the response. You are right about the "server" version, however I'm definately trying to leverage the Desktop version at its fantastic pricepoint to do the work for me compared and so far have been fairly sucessfull.

 

We have other tools (both purchased and custom written) that do the heavy lifting in our company, just looking to take advantage of what Desktop can offer for some aspects of some of our clients campaigns and jobs. It would honestly just be nicce to have some simple hooks to updating database fields in the desktop version, epsecially since it is "made" to function with variable data. Simple field updates when a person kicks off a funsionpro PDF project to fulfill an aspect of a job would really be nice, rather than really making it a blind run (as far as a database run goes).

 

I'll be happy to check out the server version and pricing in the future.

 

Bill

 

 

FusionPro Desktop is the wrong tool for this job. You should consider using FusionPro Server.

 

The problem is that you're trying to use FusionPro Desktop in an automated batch composition environment, something it's not designed to do. It is, however, exactly what FusionPro Server was designed for.

 

FusionPro is a variable data composition engine. It's not a database or business logic management system; it was never intended to be, and it never will be (especially at $799).

 

Theoretically, there are all kinds of sophisticated data processing functions that could be added to FP Desktop, but that's not what it's meant to do, and frankly, adding hooks to write back to a database from JavaScript would not provide the performance necessary for an enterprise-level application.

 

Now, FusionPro Server is a different story. It's still just a tool (though a very powerful one) for variable data composition, but it's intended to be a component of a custom application, one which you can write to manage your data and fulfills orders based on your own business logic. Any logic that you would program in a JavaScript rule inside of FusionPro Desktop to write back to a database is better handled in a custom application written in a language (such as C# or Java) that's designed to work with databases.

 

Actually, you mention that you already have a "server app" that handles most of the business logic, so that's where you want to add any other logic to update the database. Your app should automatically compose batches of records via FusionPro Server instead of manually running compositions in FP Desktop. (You can use DL Queue for this, or your own code.) What I would do is have your app mark the records in each FP Server batch request as "in progress." Then your app can capture the return code from the FusionPro Server process in order to know whether the records any given composition were processed successfully, and then update the database appropriately. This will eliminate much of the guesswork and "sheer gamble" that you have now with trying to use FP Desktop in an automated solution. You'll also gain some huge advantages in speed and scalability.

Link to comment
Share on other sites

Hi Dan. Thanks for the response. You are right about the "server" version, however I'm definately trying to leverage the Desktop version at its fantastic pricepoint to do the work for me compared and so far have been fairly sucessfull.

 

We have other tools (both purchased and custom written) that do the heavy lifting in our company, just looking to take advantage of what Desktop can offer for some aspects of some of our clients campaigns and jobs.

You can absolutely do a lot with FusionPro Desktop, and it is a great deal. :) However, if you're doing high-volume jobs within a larger application, you're going to run into limitations. That's what FP Server is designed for, to do the "heavy lifting." And we have many enterprise customers who consider FP Server a great value as well, even though it is more expensive than Desktop.

It would honestly just be nicce to have some simple hooks to updating database fields in the desktop version, epsecially since it is "made" to function with variable data. Simple field updates when a person kicks off a funsionpro PDF project to fulfill an aspect of a job would really be nice, rather than really making it a blind run (as far as a database run goes).

We discussed this informally over lunch in our development group. Our consensus was that the ability to issue an SQL UPDATE or similar statement, or some other way of writing back a database via ODBC, could indeed be a valuable enhancement to FusionPro. So it's on our list of possible new features. However, there are a lot of other feature ideas on the list which have been more frequently requested. Also, any advanced workflow capabilities like this would almost certainly be added to FusionPro Server, and not to FP Desktop. So you definitely want to look at FP Server.

 

Please keep sending us your ideas and requests!

Link to comment
Share on other sites

  • 2 months later...

Enhancement request FP-11481 sounds like it would definately be very beneficial. The server product is something that we would like to move towards, but many of our jobs could easily be processed in a desktop environment, and a simple checkout function would make this an option for us!

 

Thanks!

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...