Subscribing is a smart move!
You can subscribe to this board after you log in or create your free account.
Invite a Co-worker
Send a co-worker an invite to the portal.Just enter their email address and we'll connect them to register. After joining, they will belong to the same company.
Send Invite Cancel
Link copied. Please paste this link to share this article on your social media post.
I have a C# program that uses SmartConnector to log SBO info into MSSQL database.
It works for few days and suddenly stops logging.
Not sure what the issue is.
Other program seems to be working fine but just the logging stops completely.
What could be the cause of this kind of issue?
Server CPU?Memory?
Throttling Policy setting?
Attached a log file from smartconnector.
I don't know if it's the program issue or setting issue or server issue.
Would be nice if you could guide me to the right direction.
Thanks,
Mayumi
Link copied. Please paste this link to share this article on your social media post.
Link copied. Please paste this link to share this article on your social media post.
Hi Mayumi,
I took a brief look at the logs, and I am not seeing what I thought I might, but I do have some questions about what your C# Program is doing.
- How many different points are you pulling data from EBO?
- How often are you pulling the data from these points?
- What data are you using from each of these requests?
- What REST gateway endpoints are you using to get this data? (I see likely you are using /Values/{id}/Value)
I know there is a known issue with EBO that if you send too many EWS requests in a short period of time (and EBO has a certain configuration), than EWS requests will stop working (although I don’t see any indication of this, this could still be the case).
Based on what I do see though, I think there are 2 things you should do:
- Instead of using GET /Values/{id}/Value to get the value of objects you want. Use the /Subscriptions and /Notifications endpoints together to subscribe and read points. This is effectively batch reads, and is much much much more efficient for both your code, and EBO handling of the EWS requests (ill add this process below this email).
- If your REST Endpoint is using the ‘http’ and not ‘https’ EWS endpoint for EBO, I would suggest changing this to https. This is because they made a change where ‘redirect web clients to https’ is on by default, and doing this effectively makes it so that http EWS requests need to consume a session for every request. I could get into the details if you want, but basically what this ends up meaning is that you can only send 1000 requests in a 5 minute period before your requests get a 400 response until the sessions expire. The alternative to changing to https would be to uncheck this box in Tools > Control Panel >Security Settings like in the below screenshot:
Here is the process for using subscriptions with the REST gateway in summary:
- Create a Subscription. A Subscription defines what data will be monitored by the underlying server. Data is returned in the form of NotificationItems for a particular Notification.
- Create a Notification. A Notification is a session of shorts or a snapshot in time of all data changes. This allows the server to manage paging of the NotificationItems for an arbitrary long number of data points.
- Read the NotificationItems. A NotificationItem is the actual data that has changed for a Notification of a Subscription.
The RESTful Gateway API (and data constructs) it uses was defined to support the full EWS specification, In the case of the SoapEwsRestProvider (at least when SBO is the server) you can ignore anything not related to "ValueItemChanged" subscriptions.
Here are the above steps in more detail:
- Create a Subscription. Issue a POST to Subscriptions/Create with the new subscription definition in the body. Using Swagger, you will see the format of this body parameter:
{
"DurationInMinutes": 0,
"SubscriptionType": "ValueItemChanged",
"Ids": [
"string"
],
"PriorityFrom": 0,
"PriorityTo": 0,
"Types": [
"string"
]
}
Ignoring what you don't need for the SoapEwsRestProvider brings us to...
{
"DurationInMinutes": 30,
"SubscriptionType": "ValueItemChanged",
"Ids": [
"<< One or more unescaped EWS ValueItem IDs go here>>"
]
}
NOTE: Even though you can supply a DurationInMinutes value, SBO will always make subscriptions 30 minutes in length.
The POST result is the Subscription which you will need to create Notifications.
- Create a Notification. Issue a POST to Notifications/Create with new Notification definition in the body. Using Swagger, you will see the format of this body parameter:
{
"SubscriptionId": "<< ID of the subscription returned from step 1 >>",
"ChangesOnly": true
}
ChangesOnly indicates that you only want what has changed since the last time you called created a Notification for a specific Subscription. The first time you call Notifications/Create for a Subscription this is ignored and all data will be returned. Subsequent calls can either return all data (ChangesOnly=false) or only changes (ChangesOnly=true). In most cases you can always leave this as "true" and get what you probably want.
The POST result is the Notification which you will use to retrieve the actual data.
- Read the NotificationItems. Issue a GET to Notifications/{ID}/Items.
The ID supplied is the ID of the Notification returned in step 2.
The GET results are the NotificationItems you requested. Paging is expected for the API.
Let me know if you have any questions about this process!
Best Regards,
-Jeff
Link copied. Please paste this link to share this article on your social media post.
Create your free account or log in to subscribe to the board - and gain access to more than 10,000+ support articles along with insights from experts and peers.