Book a Demo

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - PhilK

Pages: [1]
1
General Board / Re: User-based default model
« on: February 04, 2010, 07:26:33 pm »
Grrr, I think I had a Fail Day yesterday.    :-[  Yes, it's the menu item you've specified.

2
General Board / User-based default model
« on: February 03, 2010, 09:53:20 pm »
Hi All,

We now have a reasonably large EA model running on Oracle with security/users enabled.

What would be very nice is if a user can have their own default model and not pick up the one set globally from the Diagram menu.  I've tried to do this and not been successful.

Is it possible to do?  If not can I request this as a feature?

Thanks

Phil

3
General Board / SVN Branching - How did you do it?
« on: November 24, 2009, 06:49:14 pm »
Hi All,

One of my colleagues is keen to use Subversion and branching to cater for future model development.  From the comments I've read here in the forums this does seem like it's somewhat non-trivial to do with EA.

For those who've been down this road how did you implement this?  Was it worth the pain - if any?

4
General Board / Re: The final piece of the puzzle - DBMS, VC, Secu
« on: November 23, 2009, 08:08:16 pm »
Aha!!

Got it, thanks Geert.  All I need to do now is work out how to work with svn branches in the model and everything will be complete.

Cheers

Phil

5
General Board / Re: The final piece of the puzzle - DBMS, VC, Secu
« on: November 23, 2009, 07:58:34 pm »
Thanks Geert,

Your answer prompted me to look a little closer and I've now worked out what the "Connect to Server" checkbox is on the Open Project window, boy is this so much easier than the ham-fisted way I've been importing and exporting DBMS files to a local EAP model - now it's a direct connection to the DB.  Perhaps renaming it to "Connect to DB" would make things clearer  ;)

So, to update things:

Open DBMS Model
Package Control->Check-out
Update things
Package Control->Check-in
Save DBMS Model

Is that about it?  

What's the connection with VC and the DB regarding svn locks and conflicts, can one user one user just save the model to the DB without resolving any svn issues?  If they can how do you recover from this?

Best regards

Phil

6
General Board / The final piece of the puzzle - DBMS, VC, Security
« on: November 20, 2009, 11:34:35 pm »
Hi all,

After some RTFM'ing and playing around from the replies I got for my post about restricting access to a large model I've now got DB export/import, version control using SVN and user security implemented.  Both my colleagues and I are pretty blown-away by what we've been able to do in such a short time with EA, but I think we are missing the final piece of the jigsaw puzzle.  

Reading the Version Control whitepaper and looking at the Shared Model example near the back this looks like the best fit for our usage, but looking at it I think we are just not getting the interaction between the DB and VC functions.

Does this usage look right?

1.) DBMS -> Local EAP (under SVN)
2.) SVN checkout
3.) Change model
4.) SVN check-in
5.) Local EAP -> DBMS

What's the benefit with this solution over that of the Workgroup Model?  Does using the DB store and VC mean a degree of duplication of the model?  How are the DB and VC repositories kept in sync?  Can we have different branches of the model under VC and still be in the DB?

7
General Board / Re: Restricting DB access to sub-models
« on: November 11, 2009, 07:27:08 pm »
Thanks for the feedback - the possible solutions you've suggested are where I'm weakest on EA so I'll dive into the help and focus on these areas.

8
General Board / Restricting DB access to sub-models
« on: November 10, 2009, 12:31:03 am »
Hi all,

We have a requirement to map out our technical landscape, which is maintained by several teams.  Our overview starts with a high-level package model which then drills down into the individual deployment models.

As a single eap file this works well, but what I'd like to do is break this up so the environment teams can manage the deployment models associated with their areas whilst still maintaining the overall high-level view.

This is the structure at a high-level:

OVERVIEW PAGE:
              Application 1:
                            Deployment Model 1
              Application 2:
                            Deployment Model 1
                            Deployment Model 2
              Application 3:
                            Deployment Model 1
              Application 4:
                            Deployment Model 1
                            Deployment Model 2

For example is it possible, preferably from a stored model in a DB, to allow access to the Application 2's models for certain users?

Pages: [1]