I am looking for a product that can solve a problem for me, and I hope you can help me with this ASAP.
I have a client which needs software modules to be integrated together, the following are the modules with what I think is the software that fulfills its goals next to it:
Document Management System (DMS): Sharepoint Portal.
Company Organization Structure (needed for workflows and used in DMS also): Probably custom development integrated with Active Directory and sharepoint portal.
Workflow Managment System (or BPM): Nintex Workflow.
The questions are:
Are the points above logical, or is there something missing.
Will it take too much time for development to integrate the Company organization structure with the workflow management and sharepoint, or is there a simpler solution, such as a built in Organization Structure in sharepoint or in Nintex Workflow?
I am still reviewing software solutions, I am not familiar with sharepoint, a combination of software solutions which lead to this product/solution I can use as a product later on for future clients is what I am looking for also.
For example, let's say we have a Leave request workflow process, the process is as follows:
Start -> Fill Leave Form -> Approve Form by CURRENT active manager -> save leave form data by HR team (on file or on separate HRMS) -> Close process
The organization structure is defined, and then the "CURRENT active manager" is defined for a group of people, the process will be built by a "workflow management system"/BPM software, the "Leave Form" can be a webform, or a template stored on a document management system.
I'm not familiar with Nintex Workflow however if your active directory information is up to date, in terms of the organisation structure and user details & groups, the organisation structure is probably supported out of the box by SharePoint.
Thus all that might remain is the workflow component which again could probably be created using standard SharePoint functionality, with minor customization with SharePoint Designer.
Having said that, configuring and installing SharePoint is not simple, and needs some thought.
From my experience with Nintex Workflows, it integrates really well into SharePoint and would work in a hierarchical company organization structure. If Active Directory is correctly set to indicate "bosses", "subordinates", etc, this information can be used within the workflow. For instance, "Send this workflow to my boss", followed by "send it to his boss", would be simple to program, since that information would be available from Active Directory.
Depending on what is needed, standard OOB SharePoint and Nintex can be used together to produce amazing workflows. One of the major advantages of using Nintex Workflows is that it can be used without programming. However, if programmers are available, additional logic can be added to augment a workflow (such as event-level programming).
Related
A client's employee base is struggling with using sharepoint UI as an interface. As a result the client is evaluating the option of building a custom UI on top of sharepoint to provide a better user experience; [The other option being to move away completely from sharepoint (non trivial, high cost option)]
My research indicates that you can customize the UI look and feel (but the client is looking for much more).
Another option appears to be to change/improve the experience by building PowerApps
The option I have been trying to assess,is to see if sharepoint provides adequate set of APIs/integration interfaces that allows the user to build a completely independent UI and user experience. Its effort intensive ofcourse, and feels like reinventing the wheel, and am wondering about whether others have faced similar UX callenges, and what possible solutions they might have evaluated, and path they have gone ahead with.
Under the covers, SharePoint is a SQL database and a collection of .NET classes that define each SharePoint object: SPWeb, SPSite, SPWeb, SPList, SPUser list item, document etc. Most of these objects are exposed via web services. Microsoft then built an IIS/ASP.NET based UI for the out of box user experience. There are mobile apps that are not browser based that call the SharePoint REST services to read and update lists and libraries. If you wanted to, you could built your own complete UI based on just about any technology. Is it worth it? Probably not. There are many customization options available, depending on your version of SharePoint.
(If I could post comments... :-) I would then ask: Tell us more about what the users need in the UI that is not supplied by out of the box SharePoint.)
i need to know few things please
1- is sharepoint with windows workflow foundation (a good and dependable engine)
2- i am using .NET and sharepoint, what would be the best workflow plugin for sharepoint
we need it provide easy interface to create the work flow, connect and affect oracle, SQLSERVER, work with moss2007, give us full control on the look and design of the form page as well as the approval or any pages and forms used within the workflow ( am i asking for too much !!:) )
the workflows will be used for approvals, change requests, requests of equipments, leave application, .... etc
Windows Workflow Foundation is very strong and can be relied upon for SharePoint workflows.
In the market there are lot of plugins available for workflow creation.
SharePoint Desginer
ShareVis Designer
Nintex Workflow
Captaris Workflow
I have provided a few references above. Kindly evaluate your needs and use one of them.
SharePoint makes use of Windows Workflow Foundation and it's a pretty stable and powerful solution. If you need an easy to use interface to create workflows, you may want to take a look at Nintex Workflow. We use it at the company and are very pleased with it. There are versions for both SharePoint 2007 and 2010.
http://www.nintex.com/en-US/Pages/default.aspx
I am building a publicly facing website that does the following.
Users log in.
And then view a list of their customers.
They click on a customer to view their past purchases, order them, change them etc.
This is not a shopping site by the way.
It is a simple look up tool.
Note that none of the data accessed by the website is in anything other than a SQL database - no office documents. Also, the login does not use users Windows credentials on a VPN or something like that.
Typically I would build this using a standard ASP.NET MVC website.
However the client says they want to use Sharepoint.
As I understand it, Sharepoint is used for workflow and websites that are collaboration tools such as the components you can see here http://www.sharepointhosting.com/sharepoint-features.html
Here are my questions:
Would I be right in saying that WSS is completely inappropriate for this task as it comes with an overhead that provides no benefits?
If I had to use it, would I need WSS or MOSS?
If I had to use it, would I be right in saying the site would consist of :
List item
a) Web Parts
b) And a custom site layout. How do I create one of these?
Addendum:The book Professional SharePoint 2007 Web Content Management Development looks like a good start
1.) I agree that SharePoint would be quite inappropriate for this task. A few reasons:
It costs thousands of dollars to license SharePoint for use on the open Internet
SharePoint will use a lot of resources (SQL Server, IIS, Active Directory...) that are unnecessarily demanding for your task
SP will give you very little flexibility to develop a solution in your way -- it sounds like you would need to create a database-connected Web Part in ASP.NET anyway (so that could be entirely independent of SP)
SharePoint has it's place--it can be remarkably helpful as a company's internal document management, intranet, and workflow/approval system--but it is not well suited for custom code nor Internet use.
2.) I believe MOSS would be required for the Internet license (as in the link above).
3.) SP development is not like typical relation database systems (for example, it uses flat, unnormalized tables). If your SQL matched the SharePoint way of thinking, you might be able to connect to your database as an external List using SharePoint Designer. More likely you would need to use Visual Studio to create a custom Web Part in ASP.NET.
Hopefully this'll be a few reasonable arguments you can use to help the customer see how SharePoint is inappropriate for the task... In fact, I expect just the first point (the cost of licensing) will turn them.
You can technically use WSS for this task but MOSS has more features aimed at building public facing websites. The publishing infrastructure comes to mind. It has has the CQWP which enables you to build custom interfaces which perform well in SharePoint. With SharePoint there are potentially challenges around scalability. If you know the platform well then doing something like what you have suggested would be a pretty quick task. If you don't know SharePoint and the underlying system well you could face challenges.
You do not want to approach building the final application with SharePoint Designer. It has behavior which can cause major problems with scalability. You want to create a SharePoint Solution comprising a number of features which can be easily deployed to SharePoint. Going this route does not alleviate performance problems but you are going to be closer to the right solution. You can package up the custom user interface elements as CQWPs or write Web Parts. I personally prefer to write Web Parts.
You do the overall site design in a Master Page. Pages within a site are then inheriting from this. If you have MOSS then you can create what are called publishing pages which contain your Web Parts. These are not available in WSS which is why people recommend against it for public websites.
To decide whether SharePoint (any version) is worth it, you need to find out if they are going to use any of the core features. If everything is going to be custom and you are not going to make use of any workflow or document management features in your deployment then I would stay away. To see whether you want to go further with SharePoint from a development perspective, take a look at the WSS developer labs. I recently ran an intro course at my employer using the materials from that site. They are dated, and need more info on best practices but they provide a quick way for you to dip a toe in the water and decide whether you want to go any further.
1) For the core functionality as you describe it SharePoint isn't going to add anything, BUT if you build it on SharePoints premisses it allows your client to add a lot of functionality outside the core for "free" like:
They can add Content Editor WebParts to pages where they can add descriptions, and messages
They can add lists where the customers can enter requests/comments/... and automatically have new entries mailed to anyone in the organisation subscribing to changes
The functionality you develop can be reused on their intranet
Any future small "web apps" can be included in the same site
...
So all in all unless you have a better framework to use then use SharePoint
2) WSS is all you need for now
3) Your main deliverable for now would be:
a feature with some Site Pages and a few Web Parts
a feature with a custom masterpage and corresponding css
True. Well not inappropriate but it doesn't add anything either.. but maybe in the future?
WSS is enough
You'd need web parts to expose your data, yes. The custom site layout is not necessary. If you want your own look and feel a SharePoint Theme may suffice. Even if you want some real custom layout tweaks you probably don't need a site template but you can get away with using just SharePoint Designer to edit the pages or master page.
I have been tasked with developing some large ERP applications (some legacy apps being rewritten and some new apps) in Sharepoint. As I've come up to speed in Sharepoint, I see the value and ease of creating team sites, and the examples I've found online and in books are all tailored to intranet department portals, or simple line-of-business apps for companies that don't have large legacy ERP systems. I have begun to believe that if one is going to create a large application that interfaces to several different legacy systems and spans several departments, that building custom webparts in Sharepoint just isn't the way to go.
Is Sharepoint a viable application framework for creating and hosting large ERP applications?
If so, can anyone please point me to references describing the architecture of such a system?
If not, can anyone please point me to references that I can cite as arguments for not using it?
As someone who has spent the last 15 years writing ERP applications I would say Sharepoint would be an extremely bad choice upon which to build an ERP product.
The Sharepoint table structures would be very ineffective for producing reports.
There is very limited capability for validating data.
There is no native support that I am aware of for maintaining the integrity of relation ships between documents.
Sharepoint works well as a portal into existing LOB applications, not as a platform to build a data-rich application on top of.
I'm currently deploying a ERP system written in Sharepoint for a client. I've been working on this for about a year now and from what I've seen, Sharepoint introduced as many obstacles as it made things more complicated.
Things made simpler:
Credentials automatically synced to AD.
Document handling and versioning out of the box.
Great Office integration.
Things that sucked:
You need to learn the Sharepoint way of doing things.
You have another dependency in your ERP.
It's pretty clunky.
I would recommend reading Real World SharePoint 2007: Indispensable Experiences From 16 MOSS and WSS MVPs before making a decision
I use SharePoint 2007 (MOSS) at work as part of a larger ERP installation. We heavily use the Business Data Catalog to interface with external systems and make their data visible and searchable within our MOSS portal.
In our architecture, CRUD operations on the ERP data are handled in our ERP line of business systems. MOSS and the BDC then pull the data out of the ERP database and display it as datagrids embedded in various portal pages. For example, the HR site has a MOSS page for tracking the current status of pending performance reports.
Another compelling feature of MOSS and the BDC is the ability to expose BDC datasources to the MOSS search service. For example, when a user searches for John Smith using MOSS search, the public ERP record for John Smith is inlined with the search results. Clicking on the link in the search results redirects the user to the right page in our ERP system, rather than taking them to a MOSS page.
We don't use MOSS exclusively as an ERP system, but we do use it as a presentation and reporting layer on top of our ERP system.
The MS Dynamics AX system utilizes Sharepoint extensively, in fact there are tool kits that allow users to build web parts and so forth that extract data directly out of the base AX objects. Here is a link that talks a little about the Sharepoint integration AX+SP. Currently there is still a significant portion of AX that does not reside within Sharepoint, but their direction appears to Sharepoint enable a significant portion of the application. I do not think that an entire ERP system could reside within the Sharepoint infrastructure, but from an MVC perspective it could certainly become your View infrastructure. It appears to me that this is the very direction MS is heading, but I'm just making hypothesis on their future plans.
Building custom webparts in SharePoint would not be the way to go for complex legacy systems.
SharePoint would still give you a lot of mileage if you created a custom navigation provider for the main navigation (based on an xml file for example). This would allow custom asp.net pages to display "like" they were still part of SharePoint, giving the illusion of one all encompassing app.
I think the only reason people want one huge application has more to do with Information Architecture, look and feel and findability than any technical architecture reasons.
A solution that creates separate websites for appropriate applications that are still skinned and linked into the SharePoint information architecture and still searchable from the main interface could solve the "need" for the "Enterprise" part of ERP, while still creating appropriate solutions for what are really separate applications.
The mental model I use is not so much building the apps "in" SharePoint, but creating a 'window" in SharePoint to expose the app.
We have had SharePoint where I work for a little while now, but we've not done a lot with it. We have an intranet with hundreds of ASP/ASP.Net applications and I'm wondering what kind of things can be done to integrate with SharePoint to make a more seamless environment? We put documentation and production move requests and so on in SharePoint now, but it pretty much feels like it's own separate system rather than an integrated tool on our intranet.
I've searched around to see what other people are doing with SharePoint but I've been finding a lot of useless information.
A great idea for you would be move your most used asp.net apps to run within the SharePoint site. Each app can be added either as a control directly on a pagelayout or integrated into a webpart (use the webpart to load child controls).
This would allow you to use the flexible moss interface to move the asp.net app into a unified information architecture so people can find the app easily.
SharePoint is really easy to roll out something that works, but creating a seamless intranet does require a bit of thinking outside of SharePoint itself (i.e. what should go where, which users need to see what, navigation structure...)
That is really a lot of work and requires lots of input from people outside the IT area.
A typical intranet portal segments functionality by department. Each department will probably have some custom web-based apps that you might have historically implemented in ASP.Net, and linked to from the intranet portal. With sharepoint you can start bringing the useful bits of those custom web-apps in as modular parts, so that the business owner of the portal can have more control as to how information is structured and displayed to his/her users.
Think dashboards, populated with custom metrics that only make sense to individual departments. That's one of the most obvious places to start. HR, accounting, IT, they all have metrics they want to track and display. They all have legacy systems that they might want to correlate information from. All this can be done in reusable web-parts. Since Sharepoint gives the end-user the control over layout, display, audience control, etc, you don't end up reinventing wheels all day.
SharePoint was designed to be a collaboration portal and document repository. If you have other business processes wrapped up in other internal web sites, you may not get much benefit from converting these sites into SharePoint sub-sites.
However, if there is signifcant overlap in your applications (contact lists, inventory, specs, etc.) you may want to make the investment to combine.
If you have InfoPath, you can create online forms. You can share your docs and edit them online. You can start an approvement workflow on these docs. You can create polls. You can create work groups.
Basically SharePoint is a giant and robust document store, but you can do anything what you can do in any ASP.NET web application. You can create e.g. custom workflows to automate business processes. We've worked for several customers to create corporate intranets and sometimes internet sites, so it really works. :)
But sometimes it's very hard to implement the requested features (a lot of workarounds).
Really its an intranet in a box. We pretty much run all of our day to day development tasks off of it. We keep documentation, track defects, manage people's time off etc. You can migrate your asp.net and asp applications to run under the sharepoint site. In the adminstration section you can set up web applications to run under the same site, but outside of sharepoint's control. That would probably help with the "feel" of it being completely seperate.
Sharepoint is really a shift in the way people have to think about web development and that's the key. You're no longer developing a standalone application, you're adding on to an existing framework. I would put it akin to having "silos of data" vs. a centralized database system which houses all the company's data. Once people realize that everything is connected, it will feel more like a seemless integration. My advice is to actively try and create applications in sharepoint and think about how to migrate existing apps on to it.
How about BI and reporting from an ERP?
When we know IE is uncapable to handle a page with 10000 table rows (without pagination)
Many don't realize but the success of a reporting tool depends on the performance of the grid object used - Excel and the SpreadSheet obj from the defunct Office Web Components are still the #1 in user's (accountants, managers, ceo) choice.
I think it depends on your environment. In our environment, we setup each department with their own pages and we use it for basic information, surveys, and the employee's homepage. We've built Google/Live Search and Weather.com widgets and roll RSS feeds using Tim Huer's RSS control.
One thing you can do is to create web parts to provide access to data from existing applications. Initially they could simply be read-only views, but depending on your experience they could be fleshed out to allow writes.
Another idea is to add links between SharePoint and your applications (assuming they're web based); that will at least allow a flow between them.
I haven't done it, but you could also theoretically skin SharePoint to look like the rest of your intranet.
Create libraries
Form libraries, documents libraries, slide libraries
Create standard or custom lists
Standard lists - announcements, tasks, contacts
Custom lists - suppliers, contractors, inventories, orders
Setup secure team discussion areas
Build shared team calendars
Create simple workflow processes on documents and lists