10 tips for the inRiver PIM developer
During my years as a inRiver PIM developer at Sigma I have collected a lot of experience and expertise that I thought it's time to share to my fellow inRiver PIM developers/consultants. I will start off with a set of tips to keep in mind when developing inRiver extensions. Hope that they will help you and please don't hesitate to contact me with anything PIM related. Ok, enough with the talking and let’s get started.
Wrap your code in Try-Catch’s inside your methods and log, log, log. There is almost impossible to log too much. It can feel ridiculous to log almost every step of the code but trust me. When strange things starts to happen with you extension you will thank me. Ok, you can actually log to much which will put you at risk of actually missing important information, but more is better than less.
There are different LogLevels in PIM. Grade the importance of what you are about to log and use them all. I mostly use LogLevel.Information for important information (not errors of course) and LogLevel.Debug for information important for my fellow developers if they need to investigate my code/extension. I use LogLevel.Warning for things that I don’t classify as errors but that should be easy to find in the log so we can investigate them further, if we want to. Finally LogLevel.Error. Use it only for errors! There is nothing more disturbing than false error messages in the log. If it’s not a real error but you want to highlight it, use LogLevel.Warning instead!
Always check for null references. Expect the unexpected. Log the null reference and let your extension continue working without further issues/errors with its next task.
Comment your code. Have you written an awesome, almost magical, method that does a lot of operations and calculations? Write comments! Think about your colleagues that will probably, at some point go, in and update your code. Today there is often short estimates on the development and we need to understand the code quickly to fix/update whatever we are assigned to do and then move on. Even when I look at my old code in extensions I made earlier in my career I’m like “What did I do here? Why did I write it like this?”.
Use the many functions of the inRiver Remoting API to your advantage. There is a lot of ways to get the product information out of the PIM System, good as bad ways. Load as little data as possible to increase performance for your extension. Only need to collect one Link? Skip the LoadLevel.DataAndLinks and go straight to the Link with GetInboundLinksForEntityAndEntityType or GetOutboundLinksForEntityAndEntityType method. Stay tuned for some posts about iPMC performance using the different Remoting API calls.
Learn the API, explore the possibilities and your extensions will run fast and smooth doing only what they are supposed to do.
If you are working with a lot of extension for the same project/customer use a static “PimConstants” class in a Helper project where you reflect the whole Marketing Model. Add all EntityTypes, LinkTypes, EntityFields etc in this Helper. It takes a little extra time from your development in the beginning but then it's awesome to have. This also decreases the risk of you misspelling important Model IDs while developing having to spend extra time troubleshooting and debugging your code. I don't know how many times I have misspelled a LinkType ID. With a "PimEnum" you will never have this issue again.
Use the correct Extension Types provided by inRiver for your extension. Read through the documentation about them and learn what they to. Using the wrong extension type can really decrease performance and the user experience. E.g. if you want to automatically link some entities together based on some logic do it preferable with an EntityListener instead of a Server Extension (even though they have similar event listeners). Server Extensions work before the Entity is actually saved and stored in the database and will freeze the GUI for the user while performing it’s task. An EntityListener get to work after the save event is finished and the user can move on working with whatever him/her wants to without experiencing any delays.
Only update the Entity in your extension once per run. If you have built a lot of logic and calculations and placed them in different methods, do not save (UpdateEntity) the entity in each method. Return each value to a main method and when everything is finished then update the Entity. Saving/updating entities will cost performance and should only be done when absolutely needed. There also another side effect of updating an entity more then you need. The update event will trigger all your other extensions and channel outputs (XML’s API calls etc.) and there is a risk that you will spam the receiving systems with updates.
Watch out for concurrency issues. Take this as an example: you have two extensions (IEntityListener) listening to updates on Items and both of these extensions are supposed to perform some logic and then do some type of update on the Item. This will lead to you starting to get revision mismatch errors thrown in to your face when updating the item in one of your extensions. Why? Because when an Entity is updated it will get a new revision number and your extension will have the old revision of the item loaded in to its memory. The server will verify that you try to update an item with the correct revision number. If you need two different logic operations and then update the same Entity you have to use the same extension or use the UpdateFields method in the Remoting API.
My final tips is use the existing documentation about developing inRiver PIM extensions. Use both the old on premise Wiki (http://wiki.inriver.com) and the new iPMC documentation (https://community.inriver.com). Most of the documentation found on the on premise Wiki is still applicable in iPMC extensions. In the new Community for iPMC there is a forum where you can posts questions and get help from other PIM developers. There is also a Slack channel where you can get almost instant help from the inRiver Community (inriverconsultants.slack.com).
Here’s some short info about me: my name is Daniel Jansson and currently working as a Lead Developer at Unified Commerce by Sigma's inRiver PIM Team. I have worked at Sigma for almost 3 years now and I'm certified as a inRiver Developer, inRiver Business Consultant and in inRiver Print.
I enjoy working with inRiver PIM due to the awesome possibilities to customize it and adapt it for each of my Customer’s needs. When working with inRiver PIM I can't see all the blockers due to all possibilities :)
inRiver PIM Developer