I was wondering what the general opinion of Service Connect was. Most of what I have heard in passing was that it was not a good tool and therefore not worth the money. That could just be the opinion of people who did not know how to use it and did not want to take the time to learn it.
I would like to hear opinions of the people who actually use it and know where it is good and where it is bad. Also, is it worth purchasing if you want to use it for what it is good for? There are generic ETL tools out there that could do the same stuff, so why should I buy Epicorās?
I can see a lot of potential with SC, but know less than nothing about it at this point.
I could not find any posts similar, but if someone knows of one and can point me in the right direction, there is no need to rehash the subject.
Service connect is useful for repetitive tasks.
Every evening a BAQ exports receipt info for designated suppliers and a Service Connect workflow auto magically creates AP Invoice Group and Invoices for the receipts.
Another workflow outputs āpick listsā to our vertical storage units for parts picking the next day.
Another one takes a text file generated throughout the day and āconvertsā it to a excel file and emails sales order changes from the day. Every 3 weeks we use it to unlock po release qty flag so purchasing can review the cancel/reschedule messages and re set the lock flag after MRP runs
I see it as the audience for Service Connect being non-programmers. The issue though is that itās way too complex for non-programmers. Thus we chose to save the money and just create our own c# customizations/programs in a way weāre already accustomed with.
I kinda hate it. Workflows can only be triggered from an āInput Channelā and cannot be scheduled (so we used to have to do stupid things like write a dummy file to a watched directory to kick off a workflow.)
Developing the workflows is a confusing mess of XML mapping, and troubleshooting is damn near impossible for end-users, so monitoring and cleaning up after the workflows fell to IT.
Iāve been much happier since we just started accessing the BOs directly. If you want something similar (and free with your SQL license) that is way more flexible, you can use SSIS.
I completely agree with Pedro - itās marketed to non-programmers, but even seasoned programmers will have a steep learning curve because it uses such a unique and unusual model.
Thatās the most succinct explanation I can think of for Service Connect.
We have SC, and use it like some others have posted about. So it IS a useful tool and can do things I havenāt seen a BPM do before.
It takes a technical person who is willing to learn SC and the nuts and bolts of Epicor to get the most out of SC. Iām learning it myself so Iām no expert.
I definitely have a love/hate relationship with Service Connect. \
Depending on how complicated your workflow is, once youāve spent hours upon hours going through each conversion node and mapping everything out and getting it working the way you want it to, it seems to run great without too many problems. But I would agree that there was a VERY Steep learning curve. We even had a couple of days training class with an Epicor Service Connect trainer and it still took me months (Iām not a programmer and a slow learner at times too) to finally pick up on it and get my first very simple workflow running successfully. You can get all the training in the world for it but until you really dive deep into it on your own with your own data and processes you really canāt understand it and how it can benefit you.
I really do love working with it now that I understand it. Can I even say that it can be fun!? -snort laugh- I always did like connect the dots (La la-la-la - too much Pee Weeās playhouse) as a child. You definitely want to use it to eliminate repetitive tasks for your users that donāt change too often. Any process that you can run a trace on in Epicor, you can then take that trace and import it into Service Connect to give you all of the Conversion and Reference nodes that you need to complete the process.
We currently use it for entering both Discrete and Configured Parts Orders, for mass Packing Slip creation, for Inventory Transfers from our Picks Lists (the transfer of parts from their Default Warehouse to Backflush Warehouse) - this workflow alone saves our Inventory Controllers several hours a day without having to manually transfer the parts one by one like they used to off of barcodes on the Pick Lists), we even have a Reverse Inventory Transfer workflow in case our users submit a file that they shouldnāt have or if a job gets cancelled at the last minute and we need to reverse the transfer of those parts from BF back to their default warehouses, mass Job Completions and Closings, and we have created a Vacation/Holiday Labor entry workflow that our HR department uses.
We are working on a BPM/workflow combination that will report Job Quantity with just a scan of the Job Number. And a mass Receipt Entry process. Iām sure there are other, better tools out there that we should be using but Iām so comfortable with SC now that we will continue to use it in the near future to get our moneyās worth out of it. At least until after we go live on E10 (Christmas) and can then find the time to dive into learning other methods and tools!
And I REALLY hate the Upgrade process with Service Connect (like when we went from Vantage 8 to Epicor 9 and now from Epicor 9 to Epicor 10.1) because even with the conversion process for the workflows I end up having to essentially rebuild all of my workflows from scratch and touch every single node to make sure the connections arenāt broken and the correct reference is being used. SO much work involved with SC for an Upgrade.
Iāve tried to let this one play out without jumping in on it as I have a history with it, BizTalk, MQ Integrator and the like over the past 25 years. This class of integration tooling has always had a horrible time gaining wide spread acceptance and SC is no different. Some observations from my life previous to Epicor and confirmed with SC:
You have to have a HUGE amount of data and domain knowledge to be successful with it. In some regards, being a coder is a negative as you are forced to do things declaratively (think XSLT) instead of grabbing your trusty LINQ API and writing a foreach loop.
Debugging XML / XSLT is problematic in all these environments. Devs wants a break point to set and variables to monitor. Those donāt work the same way in this world.
So it really speaks to Data Analysts that are comfortable with the data and relationships but donāt want code. If that is that class of individual then they will be fine.
As to the real concern about the product - whatās the biz need?
I see too many people buy these tools when a simpler approach is fine (External BAQs and BPMs do a LOT for you). But do you need an audit trail? Whatās the governance of this? Having confirmations that a doc was sent to a partner or never received can be business critical depending on your use case. Those are where these tools excel. Not an internal routing system but a partner network that needs governance and traceability.
Setting up a partnership and agreeing to standard doc format and data exchange to support a business relationship is wonderful and the tools support that nicely.
So channeling my inner Scotty - choose the right tool for the job.
We use to do this also. We used SC to feed a csv file to another program that did the heavy lifting, since they we found SC to be wayyyy to slow and created a windows service that basically does what SC does, but on a much faster and way more light-weight fashion. We are much happier using the windows service as we can program logging and other things to be much easier to understand.
Donāt get me wrong that SC or any of this class of tooling does not do different app to app integrations as well. And in larger orgs where the different apps are in different domains or owned by different groups itās even more valuable as the audit trail allows for easy identification on where an issue sits. Whether itās SC or one of these types of tools, just understand your needs and look at what best solved your business need. Everything has a cost, you just need to understand which gives you the value you want.
In my experience with ESC I can confirm what @ERPSysAdmin and @Bart_Elia say on their answers. The learning curve of this tool is long and painful, debugging is difficult, troubleshooting too, and looking for help is very hard because there are no āsampleā or āour of the boxā workflows you can study or look at as reference. I donāt think there are guide lines or tutorials, other than Epicor user guide or training material. Asking for help to Epicor support could be considered as consultancy since most of your questions will be HOW-TOs rather than there is a bug in ESC. You need to either contact a consultant or ask for help on this type of sites.
Once you get familiar with the tool it gets easier to automate Epicor processes using the Epicor client trace.
It may get complex when you need to add error handling and decide to whom should this errors be reported to, or if you need to rollback a transaction in case of error, or if you need to interface with external software and you need to manage code mappings, or if the input and/or output message format is complex to build/process (filter xml nodes, remove duplicates, add xml sections, etc.) this may require manual editing of the generated XLST mapping conversion and even do XLST debugging, but those may be extreme cases.
ESC is very useful when you need to get info from Epicor and then read/insert from/into a custom database using DB Operations.
Finally, consider that introducing ESC development to your toolset will require a responsible for those workflows. I mean someone who will need to be the responsible/expert who will maintain them, probably monitor/track errors, and upgrade them in case Epicor gets upgraded, specially if using the .NET assemblies, of course you will have to do all this with whatever other tool you decide to use, but if you opt for a custom .NET or a BPM, etc. any Epicor technical person may be able to take over easily.
ESC user here. In a nutshell: if we had to start over again, we would write C# code and avoid Service Connect. The promise of āthis is a tool even non-developers can useā is just not realized. And as mentioned, for a developer it is going to seem like more work and more up front learning curve.
I donāt disagree with the #OneSizeDoesNotFitAll Bart. Although, in my mind, if you donāt have anyone with in-house development or C# skills, then you really donāt have anyone in-house who can figure out ESC/XSLT/Method APIs. But Iāll admit my opinion there may be jaded since Iām a semi-seasoned C# dev and work for an SMB. Maybe a bigger company would have some sort of genius accountant or IT Manager without dev experience who could - even without dev experience - be taught by Epicor how to use ESC easier than they could be taught by the internet how to code C#. Programming always seems the easier approach to a programmer, right?
LOL agreed. A few years ago I had the same view of life - I know my hammer and everything is a nail. The awakening for me was actually watching my daughter grow into an IT person and she had a large ERP system dropped into her lap. She knows her data and is a great analyst and knows the biz side. Coding? Ummā¦ no.
It was interesting to have those chats about her companies approach to solving things. They had a bunch of business and data analysts types. No coders. Everything hosted, rent an integration coder type of model. Something in the class of SC / BT / MQ spoke to them a lot.
\ 
I always did like connect the dots (La la-la-la - too much Pee Weeās playhouse) as a child. 
