Listening to the business requirements is really the only way to help the business with information management.
But listening to the business will take you places you would never had thought of yourself.
It always starts out small and neat; can you help us with our product development projects? We only need to keep track on what articles the project contains and their state of development. It will be fun and easy! I promise! We know almost exactly what we want and we are more or less done…
As a software developer you know the drill.
These last years I have said to myself; be a pro business developer – do what they ask – do not let practical technical issues stand in the way of progress.
Well. Where did that take me?
In this particular view – one of 500 in the system – the requirements has kept trickling in one by one over the years. Everything has gone smooth and no big issues. Since we do everything with UML and declarative ViewModels and as we model everything in the same lingo the business use – there is no issue to add a few new things now and then.
Building things this way really lets the complexity sneak up on you.
The view:
It has four main levels – the project, the articles within, the packaging components for the selected article, the logistic solution and barcodes for the selected article.
The main grid has columns to show some details for each article, same for the grid for the used components. Nothing fancy and all very relaxed and moderate.
The users at the innovation department love this view – they should – they designed it.
So why do I use this simple sample to talk about complexity? I will tell you why.
Using the “Analyze expressions” – button in the ViewModel dialog I get this auto generated diagram:
A quick calculation shows that I have accessed 6x5=30 classes in one view. 30 CLASSES IN ONE VIEW!
And look at all those relations!
And this is not even the most complex view in the system – is is actually pretty typical.
How did I end up here?!
My conclusion is that if you listen to the business (you know the guys that pay your bills and that you are on a mission to help ) then you end up here.
Of course you can listen to best practice and DO NOT DO COMPLEX THINGS – but then again you might as well stay home with your mother your whole life.
If my conclusion is right – how can we deal with this? It would be hard work to optimize a way to fetch objects for 30 classes in a good and speedy fashion. Even harder to update that strategy whenever something is added or removed. This would probably require one developer becoming an expert on just this single view… But hey – we have 500 views like this… and 2 developers… So 250 views like this each… Did I mention that we release to production every 4 weeks… And we have never missed a release for the last 4 years… And that we do about 50 different updates on each sprint…
We have(had) a problem
MDriven use the declarative ViewModel and the OCL expressions it consists of to look ahead to fetch data efficiently. But recently we found that it did not do it efficiently enough. It turned out that it got tricked by derivations in attributes and associations. Derivations was skipped and they resulted in lazy fetch as the UI was drawn and that resulted in a lot of single queries send to the database. This is the same basic problem that usually kills high abstraction framework ambitions.
In our case it got obvious we had a problem once we got users further away from the server. As long as the user had a latency of 10ms it was fine – but 100ms it sucked. Since each single query sent to the db got the latency penalty of 100ms – the number of queries hit the user experience straight in the face.
I started testing the app with a simulated latency of 400ms – that is what you can expect from Sweden to Australia – not at all our use case – but it made the problem very obvious to see.
We needed to rethink how the MDriven Server can help the application.
Many things were researched – but the solution we kept we call query plan.
We have a new thing to speed up load - Query Plan
MDriven use the declarative ViewModel to find out what primary keys and what foreign keys that are needed for a particular view. It resolved OCL based derived attributes and associations to find out persistent things that much be fetched to get the information on to the screen. It also resolved all the opt-in constraints in the classes shown and also the DefaultStringRepresentation of each class used, and also the ReadOnly, Visible and Style expressions.
From this MDriven retrieves all the persistent single, multi and inner links (links to association classes). It sends this information to MDriven Server along with the root of the part of the ViewModel being fetched. It treats the structure building expressions (the nesting creators) separately from the column expressions.
The MDriven server uses the information to request the set of objects needed – and sends back all that data in 1 go.
This approach reduces the load on the SQL-Server – since now we can fetch multiple foreign keys for multiple multi links in 1 query (not possible before). It also reduces the round trips needed to the server and by doing that effectively addresses the issue we had with latency. Tests confirm a 20 time improvement in time when having 400ms latency.
Phu! We HAD a problem. Now we have an engine that does it better than what you can expect from a developer on his or her best day. And it works every time – for every view – even if I changed it to use 5 more classes tomorrow.
The view above has this in its query plan:
ProjectPackagingView
AllInstances on:
Members on this level per type:
ArticleChange.Project
ArticleChange.AffectedArticleRevision
ArticleChange.Article
ArticleRevision.Article
ArticleRevision.ComponentUsageConstellations
ArticleRevision.ActiveLogisticSolution
ArticleRevision.Changers
LogisticSolutionRev.LogisticSolution
Article.ArticleCollection
Article.PartOf
ArticleCollection.ConsistsOf
ArticleCollection.RepresentedAs
ArticleChange
AllInstances on:
User
Members on this level per type:
ArticleChange.Project
ArticleChange.AffectedArticleRevision
ArticleChange.Article
ArticleChange.Responsible
ArticleRevision.Article
ArticleRevision.Filler
ArticleRevision.Bulks
ArticleRevision.ShelfLife
ArticleRevision.LogisticsVote
ArticleRevision.SafetysVote
ArticleRevision.FormulationsVote
ArticleRevision.PackagingsVote
ArticleRevision.ComponentUsages
SalesArticle.MarketingCompany
Article.SalesArticles
Article.ArticleRevisions
Article.RegulatoryDomain
Article.ArticleCollection
ArticleRevisionApprovalVote.ArticleRevisionLogisticsVote
ArticleRevisionApprovalVote.ArticleRevision4
ArticleRevisionApprovalVote.ArticleRevision3
ArticleRevisionApprovalVote.ArticleRevision2
ComponentSpecificationRev.ComponentSpecification
ComponentUsage.UsedRevision
ComponentUsage.ArticleRevision
ComponentUsage.ComponentSpecification
ComponentSpecification.PackagingSupplier
ProjectRole.Members
Structure to reach this level from ProjectPackagingView
Project.ArticleChanges
ArticleChange.AffectedArticleRevision
ArticleRevision.Filler
ArticleRevision.ComponentUsages
ArticleRevision.Article
ArticleRevision.PackagingsVote
ArticleRevision.LogisticsVote
ArticleRevision.SafetysVote
ArticleRevision.FormulationsVote
ComponentUsage.ComponentSpecification
ComponentSpecification.PackagingSupplier
User.FavoriteArticles
ArticleRevisionApprovalVote.ArticleRevisionLogisticsVote
ArticleRevisionApprovalVote.ArticleRevision4
ArticleRevisionApprovalVote.ArticleRevision3
ArticleRevisionApprovalVote.ArticleRevision2
Article.ArticleRevisions
Components
AllInstances on:
User
Members on this level per type:
ComponentSpecificationRev.ComponentSpecification
ComponentUsage.UsedRevision
ComponentUsage.ArticleRevision
ComponentUsage.ComponentSpecification
ComponentUsage.ComponentUsageConstellations
ArticleRevision.Article
ComponentSpecification.PackagingSupplier
ComponentSpecification.Replaces
Structure to reach this level from ArticleChange
ArticleChange.AffectedArticleRevision
ArticleRevision.ComponentUsages
ComponentUsage.ComponentSpecification
ContractManufacturer
AllInstances on:
Members on this level per type:
Structure to reach this level from ProjectPackagingView
Project.ArticleChanges
ArticleChange.AffectedArticleRevision
ArticleRevision.Filler
PackagingSupplier
AllInstances on:
Members on this level per type:
Structure to reach this level from ProjectPackagingView
Project.ArticleChanges
ArticleChange.AffectedArticleRevision
ArticleRevision.ComponentSpecifications
ComponentSpecification.PackagingSupplier
LogisticSolutionRev
AllInstances on:
Members on this level per type:
LogisticSolutionRev.LogisticSolution
LogisticSolutionRev.PalletLogSpec
LogisticSolutionRev.TransportLogSpec
LogisticSolutionRev.ExtraRetailLogSpec
LogisticSolutionRev.RetailLogSpec
Structure to reach this level from ArticleChange
ArticleChange.AffectedArticleRevision
ArticleRevision.ActiveLogisticSolution
AffectedArticleRevision
AllInstances on:
User
Members on this level per type:
ArticleRevision.Article
ArticleRevision.Bulks
ArticleRevision.ActiveLogisticSolution
ArticleRevision.FormulationsVote
ArticleRevision.PackagingsVote
ArticleRevision.ArticleOwner
ArticleRevision.LogisticsVote
ArticleRevision.SafetysVote
ArticleRevision.Filler
ArticleRevision.ShelfLife
ArticleRevision.SalesArticles
ArticleRevision.Changers
ArticleRevision.DeclaredUnit
LogisticSolutionRev.LogisticSolution
LogisticSolutionRev.ExtraRetailLogSpec
LogisticSolutionRev.TransportLogSpec
LogisticSolutionRev.RetailLogSpec
LogisticSolutionRev.PalletLogSpec
Article.RegulatoryDomain
Article.SalesArticles
SalesArticle.MarketingCompany
MarketingCompany.Country
ContractManufacturer.CMValuesPerRegulatoryDomains
CMValuesPerRegulatoryDomain.AppliesTo
CMValuesPerRegulatoryDomain.OnlyInCountries
CMValuesPerRegulatoryDomain.ExtraRetailBarcodeFormat
CMValuesPerRegulatoryDomain.RetailBarcodeFormat
CMValuesPerRegulatoryDomain.TransportBarcodeFormat
CMValuesPerRegulatoryDomain.PalletBarcodeFormat
ShelfLife.ShelfLifeMarking
Structure to reach this level from ArticleChange
ArticleChange.AffectedArticleRevision
ComponentDocRefs
AllInstances on:
Members on this level per type:
ComponentSpecificationRev.ComponentSpecification
ComponentDocRef.ComponentSpecificationRev
DocumentReference.DocumentType
Structure to reach this level from Components
ComponentUsage.UsedRevision
ComponentSpecificationRev.ComponentDocRefs
self
AllInstances on:
User
Members on this level per type:
ComponentSpecificationRev.ComponentSpecification
ComponentUsage.UsedRevision
ComponentUsage.ArticleRevision
ComponentUsage.ComponentSpecification
ArticleRevision.Article
ArticleRevision.ComponentUsageConstellations
ArticleChange.Project
ArticleChange.AffectedArticleRevision
Structure to reach this level from Components
ComponentUsageConstallations_PickListPresentation
AllInstances on:
Members on this level per type:
Structure to reach this level from self
ArticleRevision.ComponentUsageConstellations
Members_PickListPresentation
AllInstances on:
Members on this level per type:
Members
AllInstances on:
Members on this level per type:
ArticleChangeDetails
AllInstances on:
User
Members on this level per type:
ArticleChange.Project
ArticleChange.AffectedArticleRevision
ArticleChange.Article
ArticleRevision.Article
ArticleRevision.ActiveLogisticSolution
ArticleRevision.Changers
ArticleRevision.BatchCodePosition
ArticleRevision.ExpiryDatePosition
LogisticSolutionRev.LogisticSolution
Structure to reach this level from ArticleChange
DocumentTypesForFilter
AllInstances on:
Members on this level per type:
ActiveLogisticSolution_PickListPresentation
AllInstances on:
Members on this level per type:
Structure to reach this level from ProjectPackagingView
ArticleChange.AffectedArticleRevision
ArticleRevision.LogisticSolutionRevs
BatchCodePosition
AllInstances on:
BatchCodePosition
Members on this level per type:
Structure to reach this level from ArticleChangeDetails
ExpiryDatePosition
AllInstances on:
ExpiryDatePosition
Members on this level per type:
Structure to reach this level from ArticleChangeDetails
DeclaredUnitPickList
AllInstances on:
DeclaredUnit
Members on this level per type:
Structure to reach this level from AffectedArticleRevision