We are doing exports and imports involving Revit files and an external data source.
What is the best approach to ID our objects imported to Revit? The ID values should stay hidden from users of our plugin so they cannot be changed accidentally.
We transfer wall, roof, ceiling and some other types, these types should have an identifier that matches the ones in our external source.
Any hints appreciated.
One option is Extensible Storage.
https://thebuildingcoder.typepad.com/blog/about-the-author.html#5.23
That link also has some discussion on other options.
Related
We've a net of vending machines of a few types and we have common API to rule them and get data from our vendors. The aim is to show live graphical schema for this net in a browser. The schema should include icons of machines, centers, servers etc. and the lines, connecting the objects with each other.
It's evident that the topography is flexible. We can set up new machines, change bindings, etc. Thus the schema should be traced automatically: I wish to give it some objects and relations as an array or JS object and see a graphical schema in the browser.
All the object should be clickable. I wish to click to the vendor icon and get statistics for it.
And last but not the least, this should work real-time. An operator should monitor this live schema, and, if trouble occurs, take some actions.
Back-end doesn't cause problems. I can do a DB and push all business-logic to server-side. But I wonder, is there a perfect way to display such stuff at front-end? Is there a ready-made solution for such kind of diagram?
Well, I don't think a ready-made solution of such a specific set of requirements exists (but I could easily be wrong on that). You could however take a look at D3. D3 is a Javascript 'data-driven' library to create dynamic charts and graphs. Maybe you can find something useful for your use case, as the library is quite flexible and offers many features.
I'm looking into converting part of an large existing VB6 system, into .net. I'm trying to use domain driven design, but I'm having a hard time getting my head around some things.
One thing that I'm completely stumped on is how I should handle complex find statements. For example, we currently have a screen that displays a list of saved documents, that the user can select and print off, email, edit or delete. I have a SavedDocument object that does the trick for all the actions, but it only has the properties relevant to it, and I need to display the client name that the document is for and their email address if they have one. I also need to show the policy reference that this document may have come from. The Client and Policy are linked to the SavedDocument but are their own aggregate roots, so are not loaded at the same time the SavedDocuments are.
The user is also allowed to specify several filters to reduce the list down. These to can be from properties that are stored on the SavedDocument or the Client and Policy.
I'm not sure how to handle this from a Domain driven design point of view.
Do I have a function on a repository that takes the filters and returns me a list of SavedDocuments, that I then have to turn into a different object or DTO, and fill with the additional client and policy information? That seem a little slow as I have to load all the details using multiple calls.
Do I have a function on a repository that takes the filters and returns me a list of SavedDocumentsForList objects that contain just the information I want? This seems the quickest but doesn't feel like I'm using DDD.
Do I load everything from their objects and do all the filtering and column selection in a service? This seems the slowest, but also appears to be very domain orientated.
I'm just really confused how to handle these situations, and I've not really seeing any other people asking questions about it, which masks me feel that I'm missing something.
Queries can be handled in a few ways in DDD. Sometimes you can use the domain entities themselves to serve queries. This approach can become cumbersome in scenarios such as yours when queries require projections of multiple aggregates. In this case, it is easier to use objects explicitly designed for the respective queries - effectively DTOs. These DTOs will be read-only and won't have any behavior. This can be referred to as the read-model pattern.
My client wants to store basic relational data in Access. So far, so good. However, ideally, he'd like for me to create an Excel spreadsheet that would allow users to create and modify data types without having to work with Access software or know about databases. To be more specific, he wants a single master spreadsheet that would let people manage data for several different "projects." Each project would have basic attributes and other related data such as employees working on it, numbered to do items with associated data, etc. I've worked with databases before and it's a neat, textbook example of a relational database. I have a model for the data already, and making an Access form to fill it in would be straightforward.
However, here's the thing: he wants creating new attributes and tables completely intuitive within the Excel spreasheet--as easy as clicking an "add student" button or even add a new category of data. For instance, in the future, he may add a list of contractors working on the project, and it would be nice to be able to have a button that would allow you to essentially create that new table. There won't be a great amount of data, though, and I'm not sure if referential integrity and normalization is crucial. For instance, the list of contractors he creates wouldn't need to be perfectly linked up so that each company only appears once in the database.
So, what should I do? Can I accomplish this within Excel spreadsheets using macros? Can you make buttons in Excel that would say "create a new table," which would (run a VBScript to) create a new database table to be associated with each project, and then allow you to format it? Should I not bother with Excel at all and basically write a Visual Basic program? I'm familiar with general programming and databases, but I am fairly new to Excel, Access, and Visual Basic. If you could point me in the right direction--to tutorials, examples, advice, general concepts, etc--it would be much appreciated.
Excel is essentially for analyzing data, while Access is essentially for storing and processing relational data. Now, having said that, what you are trying to do is probably possible but it is really not taking advantage of the features the software where optimized for.
Furthermore, adding "tables to be associated with each project" does not seem as the "relational way of doing it", like a complex solution for a simple problem.
Perhaps you should consider some alternatives:
If the amount of data is small and not very complex, would there really be any need for Access or could you just as well use Excel for data storage and data manipulation?
Depending on how the data is structured, perhaps you can create a view or stored procedure in Access and used it as an linked table in Excel?
Perhaps you can develop the set of forms you need in Access and turn it to an stand-alone application (no need for Access installed on the client's computers)
For a person entering data, Access is built so they don't need to understand relational data at all. If you let them enter data in Excel, you will have to excessively code it to give you the same control in Access or you run the risk of letting them free form data to the point you won't be able to import it back into Access.
Unless there are very complex calculations and a need for the user to 'tweak' the report layout, give them a data entry form.
Beware of the "I'm just so use to doing it in Excel I don't want to relearn it in Access" notion. The data entry can be made very intuitive and may save them time in the long-run.
Seems like there is an owner/manager who understands Excel and wants the ability to update it without you if needed.
This is a simple requirement: I want to add a set of strings to Accounts in Dynamics 2011. The string are external IDs for other systems. All the strings should be unique accross all entities.
The only way I can see to do this is define the strings as entities (say 'ExternalCode') and set up a 1:N reslationship between Account and ExternalCode, but this seems incredibly overweight. Also, defining as an entity insists thhat I give the 'ExternalCode' a name, which it obviously doesn't have.
What's the best way to implement this?
Thank you
Ryan
It may seem overweight, but think about entities as if it were tables. Would you create a second table inside MS SQL? If so, then you should create another entity. CRM is very well optimized so I wouldn't worry about this additional overhead.
Alternatively, you could always carry the GUID in the other system.
How are these unique references entering your CRM system. Are you importing the data from each of the external systems? If so I assume the references are unique in the external system? Once imported you want to make sure that any of these references are not duplicated?
Additionally, how many strings are we talking about here? If it is a small number then it would make sense to just define attributes to manage them and check for duplicates in one of the following ways:-
1) Some javascript could be used to make an oData query to confirm the 'uniqueness' of your external reference number before the record is commited. (But, this is not sufficient is records will be created programmatically in the system also).
2) A plug-in which fires on pre-create to again query the system for other records which match the same unique reference numbers and handles the event of a match accordingly.
However, if there are many of them then it may make more sense to define a separate entity as you say and then as above you could associate a new 'reference record' with the entity via a plug-in, but again, check if the record already exists and then either handle an exception or merely associate with an existing record if that is appropriate.
I think they key is what you want to do if you do find a duplicate and how these records are going to be created in the system (e.g. via UI or programmatically or potentially both).
Happy to provide some more assistance if you have some more details.
In migrating to CRM 2011, we're discovering different developers used different capitalization of custom entities and custom fields. This creates a headache for custom programming using the early bound methods. http://msdn.microsoft.com/en-us/library/gg327844.aspx. Is there a way to normalize the entity/field names before (or after) the migration?
As far as I'm aware. The only way to achieve the correct capitalisation you desire is to recreate the entities with the appropriate names.
Before or after the migration is mostly the upgrade of the CRM Server installation and modifying the database schema to reflect the upgrade, while still maintaining the current data and customisation data.
Thats as far as the "Supported" spiel goes.
As for an actual workaround. If your looking to upgrade anyway I'd be tempted to restore your current CRM 4 system to a test domain. Then look at how feasible it is to change the schema names in the actual "untouchable" crm database. I believe there is a MetaDataSchema.Entity table where this is centrally stored so i'd test this to see how usable this is and what impact it has on say the webservice.
So you face a similiar choice that I face on multiple occasions while working with Dynamics CRM. Go with the supported way, or a bit of "Yee-Ha" development. Sorry it's probably not what you want to hear!
Edit:
In regards to what to change I can't say for sure as I haven't got a CRM 4.0 system to hand only a 2011 at this moment in time. However as an example, there will be a MetadataSchema.Entity table in the [OrganisationName_MSCRM] Database. Of which certain columns will jump out. Name, PhysicalName and Logical Name.
Logical name is the one that CRM users which it defaults to lowercase no matter how you enter it.
I believe PhysicalName and Name are the ones you would be looking to change into lower case.
The actual "Name" of the entity, eg logical name is "account" whereas in CRM where it is displayed in a user friendly way is related through a table called MetadataSchema.LocalizedLabel through the foreign key "ObjectId" which in this case would be the "EntityId" field.
This is where I would be looking to do the changes as it shouldn't have an impact on the rest of the data due to the "logicalname" field being the one CRM probably uses.
As far as your generation for strongly types classes goes.
if you use latebound such as
relatedEntity.LogicalName = "new_related_account";
relatedEntity["relatedaccountid"] = entity["accountid"];
then all the properties and logical names need to be lower case. As this will use the "logicalname" property previously identified in the MetadataSchema table.
Howver using SVCUtil I can only assume it looks at the "Name" and "Physical Name" attributes to give a slightly more user friendly coding experience when it generates the file for use in custom applications.
Though if you are looking to use the early bound class generation it shouldn't be a problem as the definition file generated will provide intellisense on the correct capitalisation of attributes and properties, and if you are using late bound like the example previously it's all lower case. So it's more it will just be a bit untidy to look at than completely impractical =)