The current project I work on I shall model a business process (as they call it) with BPMN. The user interface is mostly completed. It's a web fronted based on AngularJS. There is also a wizard which should be used for user interaction during the business process. In my humble opinion every page of that wizard could be assigned to a single user task (bpmn).
Unexpectedly the wizard should behave like a wizard. There are buttons for the next and previous page and modal dialogs and a finish button. I'm worry about whether that behavior will work together with a bpmn engine or not if I model user tasks per wizard page.
Question:
Would you model a wizard with BPMN?
Should this BPMN be a runnable BPMN or traditionally implemented (e.g. plain AngularJS)?
I would model this wizard using BPMN task only if each wizard "pages" are actually independent tasks. For example if each task can potentially be performed by different users I think that make sense to model that as a sequence of BPMN task.
If a single user go through all the wizard quickly I would suggest to implement all the logic in AngularJS.
No. One task per role/swimlane, not a string-of-pearls within the same swimlane. A major point of using a structured process is getting handovers right and here there are none. Also, the performance will be bad.
Related
After creating some collection entries in Squarespace (like Blogs, Events, Products and so on..), is it possible to access the single databases with a MySql management application?
Or is it possible to create a private MySql database and force Squarespace to use it for the collection?
I would be easier to add/edit large data..
Squarespace is very much a "design-first" platform, and the data structure (or at least, the data structure as we can access it) is heavily abstracted away in the name of a simple design process. Getting data in can indeed be difficult, and getting it out even more so. It's just not a platform friendly to data management or portability.
Furthermore, you cannot run server-side code. So unless you fetch, parse and display your date entirely client-side using JavaScript (bypassing Squrespace's collections/layout entirely), the only way to serve the data to users is to first enter it via Squarespace's back-end editing UI. Custom tools have been created that, for example, add a button in the backend editing UI that allows you to manually sync collection items/data with an external source. It basically reads your source, maps the data to the collection item creation API that the backend UI itself uses, then executes until all collection items have been added in the back-end. However, this process must be manually trigered, and continually done as needed by logging into the backend, running the syncing function, then waiting for it to finish.
The task is to create several JSPs, in which the user would be able to interact by inputting information, which would be saved on a database server, so the info can be called up later.
I'm not sure if this question is constructive enough or not, but I have no idea how to even start. I know what each one of the components means, but that's about it. I have no idea how the whole process works and I don't know what's it called, so I can't even search for it properly.
Could anyone briefly describe the process from start to finish how this system would work and what should be my first concern? I'm more interested in the JSP hosting (would Tomcat be a better choice, or is Geronimo much better in my case) and the connection of JSP to the database.
You need several components and layers for an application like that, so the first thing to do is select your technology stack so you don't reinvent the wheel and adopt best practices that your frameworks include. My choice, is Spring Framework.
Your JSP's represent the View Layer of your app. You can use JavaScript/AJAX to embelish your forms and sent data to your server.
The data that the user enters in the form is received and processed by the Controller Layer. Spring MVC has some neat collection of controllers for you to use. Once the data es ready, you can pass it to the Service Layer to execute Business Logic.
The Service Layer contains Business Logic rules. Spring Framework let this Layer to be simple POJO's, and to apply Transactional logic if you wish. It's highly probable that Service Layer requires to persist some data in the Database, so it invokes the DAO layer.
The classes in DAO layer have the responsability of storing data in the database. You can use several frameworks for this, and Spring supports many of them. Also, Spring includes some inherent JDBC support with templates included.
With that you can start your project. It should run with no problems in Tomcat, Geronimo or any Java EE Container
I have created an application in C# using visual studio 2010. The application uses a database and a ton of data bound controls.
I need to save a copy of the running application with what changes the user has made to a file they can double click and get their saved state back in the application.
I know I need to use a SaveFileDialog but other than I have no idea.
If all the controls are bound to data through datasets you could perhaps serialize and deserialize the underlying datasets to/from XML files in order to create some kind of "offline data file storage" feature.
Before introducing such a feature into your application you should, however, consider all the potential database synchronization issues that are potentially created though preservation of such a saved state within your application clients.
If you really only want to preserve window layout properties (such as window size, grid column width, sorted column, splitter positions etc) you have to focus on those properties only.
Here is a thread with a similar discussion
I'm making a web service with Django that uses MySQL database. Clients interface with our database through URLs, handled by Django. Right now I'm trying to create a behavior that automatically does some checking/logging whenever a certain table is modified, which naturally means MySQL triggers. However I can also do this in Django, in the request handler that does the table modification. I don't think Django has trigger support yet, so I'm not sure which is better, doing through Django code or MySQL trigger.
Anybody with knowledge on the performance of these options care to shed some light? Thanks in advance!
There are a lot of ways to solve the problem you've described:
Application Logic
View-specific logic -- If the behavior is specific to a single view, then put the changes in the view.
Model-specific logic -- If the behavior is specific to a single model, then override the save() method for the model.
Middleware Logic -- If the behavior relates to multiple models OR needs to wrapped around an existing application, you can use Django's pre-save/post-save signals to add additional behaviors without changing the application itself.
Database Stored Procedures -- Normally a possibility, but Django's ORM doesn't use them. Not portable across databases.
Database Triggers -- Not portable from one database to another (or even one version of a database to the next), but allow you to control shared behavior across multiple (possibly non-Django) applications.
Personally, I prefer using either overriding the save() method, or using a Django signal. Using view-specific logic can catch you out on large applications with multiple views of the same model(s).
What you're describing sounds like "change data capture" to me.
I think the trade-offs might go like this:
Django pros: Middle tier code can be shared by multiple apps; portable if database changes
Django cons: Logically not part of the business transaction
MySQL pros: Natural to do it in a database
MySQL cons: Triggers are very database-specific; if you change vendors you have to rewrite
This might be helpful.
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.