FlexSim's Webserver is a query-driven manager and communication interface for FlexSim. When you start flexsimserver.exe, your computer will begin to host a website that looks like this:
This website can be accessed by typing the address http://127.0.0.1/ into a browser. You will not have any available models until you put models into your FlexSim Projects directory. The computer in the example has a model called …/Documents/Flexsim 7 Projects/my model.fsm.
A new instance of FlexSim can be started on the server by pressing the “start New Instance” button. Once FlexSim starts, click “Connect To Instance” to view the automatically generated web interface for your model. It should look something like this:
You can control your model in the browser using the controls at the top. You can also interact with open views in your model. Left click to pan, right click to rotate, and either right-and-left click or double click to zoom. Unfortunately, browsers do not give Javascript access to the scroll event of an image, so it does not work like it does in FlexSim. Additional buttons for panning, rotating, and zooming are generated for tablet devices. Click the ^ button to collapse the screenshots and save bandwidth. Graphs from Flexsim’s Dashboard are also displayed in real time. If your model has an Experimenter, a standard interface is generated for running experiments.
To connect other devices such as tablets and smartphones to this server, the address 127.0.0.1 will not work. The other device will need to be connected to the same local area network or wireless local area network as your computer. You will need to find the ip address of your computer. To do this, click the start button and type “cmd.exe”, which will open a black command prompt. Enter “ipconfig” and press enter. Your IPv4 Address should be entered as the URL in the browser in the device.
To use the server on the internet, though, your computer needs to be assigned a global IP address. Contact your network administrator.
Developing custom web interfaces
flexsimserver.exe and webserver.dll respond to certain types of queries with certain types of actions and responses. For exact details of how they work, try entering the queries into the URL bar of a browser to view the replies. Custom applications can be developed that use these queries:
- webserver.dll?createinstance=my%20model starts an instance of FlexSim running the model specified and returns a short xml reply containing the instance number.
- webserver.dll?terminateinstance=my%model&instancenum=1 terminates the first instance of FlexSim running my model.fsm on the server and returns a short xml reply
- webserver.dll?availablemodels returns an xml list of the models available to run on the server with createinstance queries.
- webserver.dll?instancelist returns an xml list of the models running on the server and their instance numbers. These are the valid possibilities for terminateinstance queries.
- webserver.dll?numinstances returns an xml number representing the number of instances running on the server including from other users. This can be used for load balancing multiple servers.
- webserver.dll?uploadmodel uploads the model to the server. A form such as the form in index.html uploads a model (or another file, such as an excel table) to the model directory. This can be disabled in the flexsim webserver configuration.txt.
- webserver.dll?deletemodel=my%20model deletes the model (or another file) from the model directory on the server. This can be disabled in the flexsim webserver configuration.txt.
- webserver.dll?allfiles returns an xml list of all files in the model directory on the server.
- webserver.dll?queryinstance=my%model&instancenum=1&... queries an instance of FlexSim. FlexSim decides how to reply to the request. This is the gateway to the main functionality of communicating with a model. The request is handled as seen in this picture:
- webserver.dll?getjobresults=1 returns a JSON summary of a job submitted with a submitjob query.
- webserver.dll?getstatus=1 returns a JSON summary of the job status of a job submitted with a submitjob query. This is a shorter version of a getjobresults query that does not include the full description of the results.
- webserver.dll?getqueuelength returns a JSON number representing the number of jobs in the job queue
- webserver.dll?canceljob=1 cancels a job submitted with a submitjob query if it is incomplete or waiting.
- webserver.dll?getjobquery=1 gets a JSON string such as "queryinstance=my%20model&instancenum=1" that can be used to interact with models run by the job manager. If the job has no running instance (such as if it is waiting or complete), an empty string will be returned because the instance cannot communicate right now. When communicating with an instance of Flexsim started by the job manager, the instance may be shut down at any time. This is why instances started by the job manager are not listed in an instancelist query.
- webserver.dll?submitjob should be the action of an HTML form like this one containing a job description in JSON format. The reply will be an id for use with getjobresults queries.
<form action="http://127.0.0.1/webserver.dll?submitjob" method="POST">
<input type="hidden" name="job" value='{"modelname":"my%20model","timeout":3600,"priority":5,"setupcommands":[{"command":"settable=modelparameters","data":"values=[[/"firstParam/",0],[/"secondParam/",2],[/"thirdParam/",/"hello/"]]"},{"command":"setrunspeed=100000000"},{"command":"setstoptime=86400"},{"command":"toolsnodefunction=setupscript"},{"command":"run"}],"resultcommands":[{"command":"getnodedata=/Tools/TrackedVariables/WorkInProgress"},{"command":"getnodedata=/Tools/modeloutput"}]}'>
<input type="submit">
</form>
The JSON object must have a "modelname" field, which is the name of the model on the server. It can have a "timeout" field, which is the maximum number of seconds to wait for the model run to complete. It must have a "setupcommands" field, which is an array of command objects. It must have a "resultcommands" field, which is an array of command objects. Command objects must have a "command" field, which is the part of a queryinstance query after webserver.dll?queryinstance=my%20model&instancenum=1&id=1&... Command objects can also have a "data" field, which is the body of the HTTP request, typically containing data from POST requests. Command objects can also have a "verb" field, which is usually "GET" or "POST".
The job will be done as soon as the server is able to make more instances of FlexSim. A createinstance query will be created, followed by a queryinstance=my%20model&instancenum=1&defaultpage query, whose replies are ignored. The replies to each of the setup commands are then stored, followed by polling the model with queries like queryinstance=my%20model&instancenum=1&id=1&getrunstate. When the runstate is 0 (when the model is finished running), the replies to the result commands will be stored. A complete summary of the run in JSON format can be sent as a reply to a getjobresults query.
The default webpage for a model is generated by using a template found in the tree at MAIN:/project/exec/globals/serverinterface/pagetemplates/default. An html page can be made for a specific model by putting the html into a node created at MODEL:/Tools/serverinterface/defaultpagetemplate. This page can include the php-like <?flexscript … ?> tags to generate dynamic material. This will override the default page of the model.
Custom query types can be modified or added by adding subnodes to a node at MAIN:/project/model/Tools/serverinterface/queryhandlers. These can be based on the query handlers at MAIN:/project/exec/globals/serverinterface/queryhandlers.
Custom functionality and custom query types for querying the model can also be written for a model by making a flexscript node at MAIN:/project/model/Tools/serverinterface/sendreply. This node must call webcommand(“httpsendreply”,replynode); once to send a reply to the query. This will send a reply in different forms, depending on the type of data in the node given as a parameter. If the node has string data containing a syntactically correct HTTP reply with HTTP headers as defined by http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html, then it will be sent as-is, giving developers full access to send any type of HTTP reply desired. Refer to the code in MAIN:/project/exec/globals/serverinterface/sendreply for an example, which can be copied and edited as needed. Remember that the defaultpage and getrunstate queries are used by the job interface.