Hosting Custom Order Rules in my own SPS API application

[toddsou]

Hi-

As you know, Select offers users the ability to build Custom Order Rules using Iron Python. These rules can affect the behavior seen by the end user for such things as field validation, default values, to name a few.

I want to build a small c# console app using the SPS SDK and allow it to also host those Iron Python Custom Order Rules.

This post appears to be close to what I'm looking for:
https://stackoverflow.com/questions/705 ... -sharp-app

Guidance appreciated.

Thank you.

[BobRichards]

The CORs are part of the order and must be hosted by the SelectServer instance you connect to with your client. I assume you want to create an app that connects to Select (see the SDK topics How-To / Standalone Application Development). All of the Python engine creation code is in the Select Client and Server DLLs and you cannot host it. Remember that order rules run independently in both the Client and Server. That means that they must be built into the order.

The stackoverflow link you are referencing discusses how to create a Python engine - which you are free to do - but it is only for your code and would not become part of the Select order nor add to the CORs.

Can you share specifics of what are you trying to code for? Perhaps there is another way.

[toddsou]

Thanks for the reply, Bob.

I'm hunting a memory leak attributed to the spssvc.exe, and suspect it is either one of our server packages or one of our CORs. I have put some long-looping test harnesses around the server packages' logic routines and the memory usage held steady so I feel fairly confident that they are not the culprit.

And so now I'm looking to do the same for the CORs logic in some way. I'm brainstorming here, but I think it would be something like this:

Build a c# standalone console app that would closely mimic what the SPS service does in order to host the script engine and then import the COR under test. I have extracted each COR module's text to a .py file on disk to allow for direct import to the app. The app would then directly call the COR method, passing the necessary params in order to excercise the COR's logic. Long-loop over that, and watch memory usage by the app. Rinse and repeat for the remaining CORs.

Feedback appreciated.

[BobRichards]

As a thought...

If you write a Select client package, you could test CORs by loading an order with a single COR and exercise it in your client package. With the order open, you can write fields via the API that the COR is wired up to. It will allow you full control over orders and running CORs. Monitor application "select.exe".

Doing this with a server package might be slightly more difficult but it should be the same. Just monitor service "spssvr".