When we create a product, few xml files are generated for the product, its offerings etc. How is the data from these xml's read into the pcf file?
There's no direct connection between the product model xml files, and the PCF files. The product model is used to tell the PolicyCenter back end all the information about your products, the availability of these, allowed values for coverage terms, questions etc...
The PCF files are just your views for PolicyCenter, they determine what html is generated for the front end. They will indirectly access the data in the xml to determine whether a given offering, coverage, line etc... is available, and its default state, and certain validations.
Related
We have a sharepoint website and as part of functional process across the website where there are lot of documents been uploaded. Currently they are been stored into database which results in very bulky table in terms of size. My initial approach was to utilize sharepoint to store the documents into file library. Does anybody think database is the wiser options and why or any other approach which is performant and better to store confidential files?
Using a database for storing documents is not a recommended approach, not only it will have large size but will be hard when it comes to maintenance and performance.
If you have a SharePoint server, why not go with a library or multiple libraries to store documents. You will get the below advantages when using SharePoint.
1.Permission management : you can set up access to documents and choose who access what.
2.Search : if there is a search service running you can search through your libraries.
3.OWA : office web apps can be used to open documents on the browser.
4.Audits : You can enable audit logs to see who does what.
Remember, SharePoint is a CMS and there are other options like MMS etc, but it stores the documents in a database too, its designed well so you dont have to worry much about it. If you go with your custom solution you will have to do a lot of custom development and testing.
I never recommend saving files in the database. The easiest approach is to store them on the server in a directory and only save the file names in the database. This makes it easy to show them via a URL in a browser as well. Create a table with a column for the OriginalFileName and one for the ActualFileName. When i save a file to the server after its uploaded i usually change the name so you never have complications with duplicate file names. I use a GUID as the actual file name when its saved and save the original file name in the database along with the actual so you can get both back.
I am looking for a document repository solution (hosted internally, not cloud-based) that has the following set of features:
Statuses: Users can set a status (pending, complete, etc) on the document. Notification system based on the status change.
Workflows: Ability to define who the documents go to based on the different statuses. Be able to customize these workflows.
Tagging: Users want to be able to tag different sections of a document with certain key words.
Search: Ability to search for documents based on content within the document as well as for tags.
Merging: Ability to select different pages and/or content within one document and merge that content to another document. Kinda like copy and paste, but more seamless.
Archiving: We need to be able to archive documents in some way.
Permission System: We want to limit document access to users based on roles (read, edit, delete, etc.)
Real-time collaboration: Users should be able to view documents at the same time.
I know that SharePoint has support for at least some of these features, but I am not sure which ones. I am having a difficult time navigating Microsoft's website on what SharePoint can actually do.
So my question is, do you guys know which of the above features SharePoint supports? Oh and any recommendations for other document repository solutions are also welcome.
Assuming that you are targeting SharePoint 2013 on premises;
Status - this can be done by adding a column to document library
Workflow - this is available out of the box. You can also enhance workflow capabilities with adding a third party workflow engine (e.g. Nintex)
Tagging - I am not sure I understand "tagging different sections of a document". Document tags are supported in SharePoint
Search - supported
Merging - this is "document set" functionality in SharePoint. But, it is limited to creating a set of documents with multiple files. Not sure this is what you want
Archiving - Look at records management processes in SharePoint. You can set file retention policies. You can declare records (so no one can change/delete them). Depending upon your definition of Archiving, this may or may not work for you.
Permissions System - most definitely available. More granular than NTFS IMHO
Real Time collaboration - available
Hope this helps
I have a requirement wherein I have to obtain all the files of a web recursively (i.e. traversing through the folders and sub folders) and display them for the user through SP Object Model.
This has to be security trimmed, in the sense, if the user doesn't have sufficient privileges to view or open the file, then that file shouldn't be taken into account. Is it possible to obtain all the files without looping through each and every document library, folders and sub folders?
Also, I don't want the default document libraries like web part gallery, master page gallery,etc to be listed out. Any insights on how to achieve this?
The Content Query Web Part can get you most of the way there. Out-of-the-box you could set this up to show all files (based on a content type or content type category) from a site collection. You could even filter to remove system files although that might be a little tricky to get the filters right.
If that doesn't get you far enough, then you could write a web part that extends the Microsoft.SharePoint.Publishing.WebControls.ContentByQueryWebPart class. You could override the Filters (by setting the FilterField1, FilterType1, FilterOperator1, FilterValue1, etc).
The security trimming should happen for you by the default behavior of the ContentQueryWebPart. The Web Part and Master Page galleries will get filtered out based on your content type settings so you shouldn't have to worry about those.
I'm looking at the architecture for a DW project and there will be the need for some manual collection of [structured] data eg the monthly accounting results from a country manager where they need to complete a form and fill in half a dozen values etc.
I really like the idea of using SP and InfoPath for this as it gives the security, the workflow and the customisability etc that mean it can be easily deployed as the client already has SP rolled out. The bit I am less clear on is how, technically, we might interface to the SP workflows and the forms themselves. Ideally the data would end up dropped into a database and we would use our [their!] standard ETL (DataStage, possibly sat on a linux server) via ODBC and pick it up like any other datasource but I am not sure what this requires on the SP side. The alternative would be to get at the XML of the individual forms and pull the info from there.
Are these appaoches feasible? What would need to be set up on the SP side in order to make this integration as robust and seamless as possible? Can anyone point me at docs/reading matter that might give me some more background info?
Thanks,
Dex
First up, accessing sharepoint's databases is never the answer to any integration question. You should treat it as a black box.
So, how should you get the data? Web Services + HTTP. SharePoint offers a large amount of Web services to get at the data you need. If you're working with IP forms, then ultimately you will need to grab the resultant XML file from the document library and parse it to get the data you need. The Web services can be used to enumerate the IP forms, and you can use straight HTTP to grab to xml file. This is probably the approach that would be offered by most experienced sharpepoint people.
I am working on a SharePoint application where the data is kept in lists. For ease of reporting, we create views in SQL Server 2005 that link lists together, and our Reporting Services model is based on these views.
As users add/modify/delete fields, our views become stale. When we recreate the views, some reports are no longer valid. What is the best way to allow users to modify fields and update the existing reports automatically (or notify an admin that a report has been broken by changing a field)?
Have you thought about reporting directly off the Lists, maybe using a product like http://www.enesyssoftware.com/ which is a reporting service data extension. This still won't help with your reports going stale when your users add/remove column.